Home

RCS Common Core 1.1 Service Description Document

1. Proposal to satisfy Example Example Example implementation Implementation Implementation Implementation Scenario 1 Scenario 2 Scenario 3 scenarios CS Voice as Always on Always on Always on Always on in 15 4 1 1 to 15 4 1 2 SMS as in Always on Always on Always on Always on 15 4 1 5 IP Voice as in Configurable Always on Always off Always on 15 4 1 3 to 15 4 1 4 PS xMS as in Configurable Always on Always off Always on 15 4 1 6 to 15 4 1 8 RCS Chat as Configurable Always on Always off Configurable in 15 4 1 9 RCS File Configurable Always on Always off Configurable Transfer as in 15 4 1 10 RCS In Call Configurable Always on Always off Configurable Services as in 15 4 1 11 RCS IP Video Configurable Always on Always off Configurable as in 15 4 1 12 ViLTE IR 94 Configurable Always on Always off Configurable as in 15 4 1 13 Provisioning Configurable Always on Always off Always on as in 15 4 1 14 V2 0 Page 152 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document PS Always off Always off Always off Always off data Internet Access Table 32 Summary of proposed implementation and desired behaviour of services when DATA is OFF 15 2 Technical Information R15 5 1 The technical realization of data off behaviour is applicable to devices in the following way R15 5 1 1TE1 Fo
2. page 84 fulfilling requirement R8 3 5 e Audio Messages are represented in Chat Conversations fulfilling requirement R8 3 9 e Status notifications for incoming Audio Messages shall follow the status notification for incoming File Transfer request as required in File Transfer incl Geolocation Push page 84 and fulfilling requirement R8 3 10 V2 0 Page 101 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document R8 4 22 Requirement R8 3 4 shall be implemented locally on the device The Audio Messaging icon has to be embedded in the device R8 4 23 Regarding requirement R8 3 7 the message s time and date information are retrieved from the corresponding elements conveying the File Transfer request as per 1 to 1 Chat Group Chat and File Transfer incl Geolocation Push When using the FTOHTTP technology the duration is retrieved from the lt playing length gt element of the File Transfer via HTTP message body as defined in Table 76 of RCC 07 When using the FTOMSRP technology the duration may be derived by the Client via an extrapolation from the size of the AMR file R8 4 24 A file being identified as an Audio Message according to its format defined in section 8 3 Overview page 99 shall be associated with a specific icon embedded in the Client 9 Messaging for Multi Device 9 1 Description Multi device Messaging allows users to vi
3. 13 3 Technical Information 13 3 1 Overview There are three different enablers that can expose different types of RCS API 6 Device or Terminal API 7 Network API 8 UI Hook V2 0 Page 140 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document This current version only covers Device API Technical requirement matching for Network API and UI Hooks will be completed in a maintenance or future release of the Common Core The technical answers to above requirements may have technical requirements on several elements of the end to end RCS infrastructure e The terminal and associated RCS stack exposing Terminal API e The UNI NNI interface e The application using the Terminal API e The service provider RCS infrastructure 13 3 2 Requirements matching R13 18 1 For Terminal API requirements of user stories US13 1 US13 2 and US13 3 are covered by RCC 53 R13 18 2 The requirements of user story US13 4 is left to device implementation R13 18 3 Requirement R13 5 1 for identification of the services offered by the application is done through the IARI which uniquely identifies the service This is ensured e At the UNI level through the definition of the IARI and its usages in sections 2 6 1 1 3 and 2 6 1 2 6 of RCC 07 NOTE The term application is equal to the term Extension as used in RCC 07 e At the terminal level through the procedures defined in sections
4. After reactivation of a RCS client e g via its toggle RCS client switch triggering deactivation of the currently active RCS client all its entry points are activated again and its toggle RCS client switch is removed from the settings menu once the user has left the settings menu A RCS native implementation may enter into the following states depending on certain conditions R2 3 9 R2 3 10 R2 3 11 V2 0 RCS permanently disabled This state is the starting point for a device that is started up for the very first time or has been put by the network into this state It leads to the automatic service activation process when a user switches on the device for the first time if the operator is RCS enabled and the user has data connectivity RCS on set up process RCS is in the middle of the service activation process It is not yet visible on the device but HTTP requests are active OM In the event of a SIM swap if a configuration associated to the SIM either because the device is able to resolve the MSISDN or via the IMSI is available in the device then it shall be used otherwise the use case is equivalent to a first time configuration Independent of the outcome user data e g Page 13 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document V2 0 configuration messages contacts etc shall not be deleted from the device in the event of a SIM swap R2
5. R6 14 3 R6 14 4 OM On receiving a Group Chat message the user shall be notified with graphical and sound elements similar as the device notifies incoming SMS messages if not stated differently in this requirements document For audio notifications device audio related settings shall prevail Any audible or visual notification shall be suppressed in case the reception is visible on the currently active screen of the device e g if the user is currently on the chat screen with a person and a File Transfer is received If the device supports a notification LED for screen off notification then this LED shall flash as long as there are unread RCS messages The colour should differentiate from notifications of other applications but may be identical for all Operator Messaging services US6 15 As a user want notifications of rapidly sequenced incoming Group Chat Messages intelligibly aggregated and counted R6 15 1 R6 15 2 R6 15 3 R6 15 4 Rapid sequence of incoming Group Chat Messages in one Group Chat Conversation shall be consolidated into one audible notification per Group Chat Conversation Consolidation of visual notifications is not affected On selection of the visual notification for a single new message or multiple messages from one Group Chat Conversation the user shall be directed to the respective Group Chat Message On selection of the visual notification for two or more new messages from different Gr
6. e Availability is down to service provider policy e Services that can be implemented on the device client without network interaction shall be always implemented i e Calling Line Identification Presentation CLIP Call Waiting CW and Call Hold NOTE Configuration of supplementary services e g Call Forward Busy CFB Call Forward Unreachable Call Forward No Reply and Conference Call shall only be possible from the primary device and only when it is in cellular coverage Based on operator policy the supplementary services configuration may however be applied to all types of calls targeted to all types of devices i e primary or secondary R10 13 10 The requirements of US10 11 shall be implemented locally in the device R10 13 11 Requirement R10 12 1 shall be implemented locally on the device 11 IP Video Call 11 1 Description Video calling is an important feature to evolve the operators calling experience Video calling will offer a sustainable and reliable video calling experience across multiple devices and different bearers triggered by a single video calling button Widespread reach across user locations and use cases will be ensured This section describes the User Stories and Service Requirements for the core IP Video Call service and all features around that core 11 2 User Stories and Feature Requirements US11 1 As a user i e user A want to initiate from various call related entry points e g co
7. R6 5 7 OM In the case where Group Chat participants leave the conversation all other Group Chat participants shall be notified with graphical elements inside the Group Chat Conversation only US6 6 As a user don t want to deal with Group Chat invites and acceptances want to join a Group Chat Conversation whenever I am invited to participate R6 6 1 OM Any user who was invited to a Closed or Open Group Chat Conversation shall automatically become a participant of that Group Chat Conversation no invite acceptance handshake process required R6 6 2 The user shall be able to see who originally set up the Group Chat US6 7 As a user want to send text Group Chat Messages to an existing Group Chat Conversation R6 7 1 Any participant in a Group Chat Conversation shall be able to send messages to all Group Chat participants R6 7 2 If the originating user tries to send messages to other Group Chat participants while not connected to the RCS platform offline the messages shall be queued locally on the device and sent out once the device reconnects to RCS platform Online again US6 8 As a user can send a Group Chat Message to an existing Group Chat Conversation like a text and it is just delivered Recipients do not need to explicitly accept any single message R6 8 1 Any message exchanged in the Group Chat Conversation shall be received on other participants devices without any form of acceptance
8. TE1 defined in section R3 3 1 shall use an Options Application Server as presented in section 2 6 1 1 5 of RCC 07 to allow presenting an aggregated view of the contact s available services to the requester R9 5 4 Message management e Unless clearly stated otherwise all new messaging requests are forked to all registered RCS clients devices or interfaces of the intended callee see requirement R9 3 12 as per IMS rules e Standalone messages shall be processed as described in section 3 2 4 5 of RCC 07 e A 1 to 1 Chat invitation shall be processed as described in section 3 3 4 1 7 of RCC 07 e A Group Chat invitation shall be processed as described in section 3 4 4 1 8 of RCC 07 R9 5 5 Device or interface switching e A user can change from one client to another during a session see section 3 3 4 1 7 of RCC 07 R9 5 6 Central storage and synchronization e Fulfilling the requirements of this section requires a service provider to deploy a Common Message Store and a synchronization client on each device or interface see RCC 09 and RCC 11 e Standalone Messages interactions with the Common Message Store shall be processed according to sections 3 2 1 5 3 2 4 5 and 3 2 4 7 of RCC 07 e 1 to 1 chat messages interactions with the Common Message Store shall be processed according to sections 3 3 4 4 and 3 3 6 6 of RCC 07 e Group Chat messages interactions with the Common Message Store shall be processed acc
9. V2 0 Page 145 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document R14 4 2 R14 4 3 R14 4 4 User Authentication via the basic or digest access authentication based on credentials user name and password exchanged between the application and the peer network application Since the RCS user stories aim to prevent that the user is involved in the exchange of the access credentials an automatic provisioning of the credentials is applied via device provisioning The digest procedure in itself is secure and robust against attacks It is vulnerable to attacks to discover the credentials via access to the application s key store or spoofing attacks based on the credential management procedure e g malware pretending to be an RCS application Network based user identification via header enrichment or GPRS IMS Bundled Authentication GIBA which is in fact a single sign on SSO prolonging the authentication of the user at the time of bearer set up for the usage of services within the bearer session The bearer set up in a 3GPP network is typically based on the UICC based Authentication and Key Agreement protocol The IP address assigned at the time of bearer set up is used as the token to identify the user within the existing bearer session This identification mechanism is secure in itself i e it is not possible for an attacker to claim another identity within
10. 0 and or FT HTTP CAP ALWAYS ON 0 As an RCS user with multiple RCS enabled devices I shall have access to all my SMS MMS or the equivalent Standalone Messages RCS 1 to 1 Chat RCS Group Chat messages message states and RCS related content including files and events related to services listed in R9 3 4 for full list of services from any of my devices and interfaces shall be able to manage all of the above messages and content in the same way on every device and interface i e in the same way as on the primary device R9 3 1 OM A user s complete set of conversation histories with their contacts shall be stored on a network repository NOTE This is the Common Message Store or CMS R9 3 2 This store shall be used for RCS enabled devices and interfaces to be able to receive up to date message and conversation histories R9 3 3 OM All contents on the Common Message Store shall be kept for an MNO configurable period of time and or up to a configurable quota size per user R9 3 4 A conversation history shall include all events that a user has sent and received during that conversation on any of their devices and or interfaces An event can be a message a piece of content or a message or content notification associated with any of the following services the user has access to R9 3 4 1 SMS R9 3 4 2 MMS V2 0 R9 3 4 3 Chat messages R9 3 4 4 Group Chat messages Page 103 of 166 GSM Association Non confidential Official
11. B Party R4 15 2 lf A Party is not registered to RCS offline MMS shall be considered the default File Transfer Service proposed by the device logic NOTE In this case RCS File Transfer shall not be sent R4 15 2 1lf MMS messages cannot be sent immediately MMS shall be composed and locally queued until data connection is restored R4 15 3 lf A party is registered to RCS online and in cellular coverage the current capabilities of B party determine the proposed messaging service R4 15 3 1A capability check for B Party shall be performed in the background whenever A Party enters the messaging composer and selects a recipient or selects File Transfer from any of the service entry points on the device NOTE The operator Capability Server may deliver capabilities instead of B Party s device R4 15 3 2 f B Party is registered to RCS online then RCS File Transfer shall be the proposed File Transfer service NOTE Taking into consideration the exception detailed in R4 15 3 3 R4 15 3 3Exception if B party is a non Integrated non Seamless Messaging user and a conversation is already in progress between A and B and the last message in that active conversation was sent or received using xMS or after operator configurable timer DELIVERY TIMEOUT expires for a sent RCS message in that active conversation then MMS shall be the proposed File Transfer service R4 15 3 4 f B Party is not available for
12. Connect to Cellular network Connect to RCS User B Connect to Cellular network Receiver RCS user Connect to RCS Default FT service Proposed Service User Choice On device caching of unsent files required and user shall be informed If B Party is known to be a non RCS user Exception see Error Reference source not found Table 15 Table to explain and summarize static conditions and proposed Messaging Service by the device logic 4 2 7 Multimedia Message Service Selection The sections above sections 4 2 3 to 4 2 6 describe the logic for selecting the preferred messaging service for individual messages and File Transfers in a conversation As described the preferred messaging service is influenced by the IM_CAP_ALWAYS_ON and FT_HTTP_CAP_ALWAYS ON configuration parameters A client configuration where these two parameters are set to different values e g where IM_CAP is set to O and FT_HTTP_CAP is set to 1 can result in two different messaging services being selected for different messages in the same conversation For example SMS being selected for text messages and RCS File transfer for files This would be the case with a client configuration of IM CAP_ALWAYS_ON 0 V2 0 Page 53 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document and FT_HTTP_CAP_ALWAYS _ON 1 in a conversation where the A party is Online a
13. If set to 1 RCS IP video call shall prevail e To resolve the potential race conditions o If inviting for or accepting a video share subsequent RCS IP video call shall be rejected and vice versa V2 0 Page 133 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document o If a video share one direction session is in place then the only choice is video share e Note that consistently with section 12 3 video share bullet if the ViLTE service is available then ViLTE shall be used independently of the value of RCS IP VIDEO CALL UPGRADE FROM CS 12 3 2 1 1 Video Share R12 24 4 The realisation for requirements US12 3 R12 3 1 and R12 3 2 is covered in section 12 3 R12 24 5 The realisation for requirements of user stories US12 4 and US12 8 is covered in section 12 3 video share bullet R12 24 6 Regarding requirement US12 6 Video orientation it shall be implemented following the image orientation extension as defined in 2 7 1 2 2 of RCC 07 R12 24 7 The requirements for user story US12 7 shall be implemented locally in the device R12 24 8 For requirements of user story US12 8 procedures as described in sections 3 6 4 3 4 and 3 6 4 3 5 shall be followed R12 24 9 For requirements of user story US12 9 and for the case of bidirectional video share section 2 7 1 2 1 of RCC 07 shall be taken into consideration R12 24 10 For the requirements of user story US1
14. Rear Camera Opposite to the front camera positioned on the back of the device A operator messaging service whereby the user is not aware of the messaging Seamless l i technology used but the device network determines which messaging Messaging technology is used Secondar Terms used to describe any access to a user s RCS account and service y features from a device or interface not containing the SIM associated with the device or l l primary identity A user may have several secondary devices and or interfaces Secondary nae ap available to access their RCS service including devices containing SIMs not Interface Fanaa l associated with the user s primary identity Service Service availability is a state of a specific user that is determined using availability Capability Discovery processes SDD Service Definition Document a document that describes the User Stories Requirements and Technical Implementation Details of specific RCS services TE Technical Enabler A thread or messaging thread is the history of all messages or files Thread or exchanged in past between two users including message exchanged in past messaging i l which are not part of the current conversation This notion can be extended to thread n Group and then represents exchanges between all participants of the group UI User Interface xMS The traditional operator messaging services known as Short Message Service SMS and Mu
15. chat SMS or File Transfer i e chat MMS service was used to convey the message In case the operator has changed the Messaging or File Transfer Service on the terminating leg to ensure delivery the A Party UI shall not change the Messaging or File Transfer Service indication e g A Party creates an RCS Chat Message the operator terminates this message as xMS if the B Party has cellular connectivity but is not registered to RCS In this case a message is indicated as RCS Chat on the sending device and may be shown as SMS on the receiving device The device shall provide the user with an option to resend pending or failed RCS messages or files by another Messaging or File Transfer Service e g but not limited to cases where the A Party loses connectivity due to changing radio conditions If in this case the initial message was pending and has not yet been sent the device shall not make further attempts to send the message using the attempted Messaging Service but shall propose the alternative Messaging Service to be used instead If there are also further more recent undelivered RCS messages sent by the A Party in that active conversation then the user is asked whether they would like to resend just the single message for which the timer has expired or all of the undelivered messages US4 10 As a user want to be in control of the default messaging service in Operator Messaging R4 10 1 R4 10 2 V2 0 A setting sha
16. lt characteristic type UX gt lt parm name ipVideoCallNonRCS value X gt lt parm name messagingUX value X gt lt characteristic type Ext gt lt characteristic gt Table 17 UX sub tree associated HTTP configuration XML structure Node lt x gt UX Common Core related parameters used to control the UX of the client are placed under this interior node Status Occurrence Format Min Access Types Required One node Get Table 18 UX MO sub tree addition node e Values N A e Type property of the node is urn gsma mo gcc ux 1 0 e Associated HTTP XML characteristic type UX Node lt x gt UX messagingUX Leaf node that describes whether the seamless messaging experience or the integrated messaging experience shall be used If not instantiated the seamless messaging experiences shall be used Status Occurrence Format Min Access Types Required ZeroOrOne Bool Get Replace Table 19 UX MO sub tree addition parameters messagingUX e Values 0 the client shall use the seamless messaging experience 1 the client shall use the integrated messaging experience e Post reconfiguration actions As the client remains unregistered during configuration there are no additional actions apart from de registering using the old configuration and registering back using the new parameter e Type property of the node is urn gsma mo gcc ux 1 0 messagingUX e Associated HTTP XML characteris
17. 1 to 1 Chat page 61 e The RCS File Transfer Service refers to the service defined in File Transfer incl Geolocation Push page 84 e The Short Messaging Service SMS is provided by the client as follows o Ifthe Short Messaging Service is selected by the client and the standalone messaging service is enabled by the service provider via the configuration parameter STANDALONE MSG AUTH as defined in sections A 1 4 3 and A 2 1 of RCC 07 and the client is registered in IMS then Standalone Messaging as defined in section 3 2 of RCC 07 shall be used o Otherwise if supported by the device the client shall use the Short Messaging Service as defined in BGPP TS 23 040 or the Short Messaging Service over IP as defined in IR 92 e The Multimedia Messaging Service MMS is provided by the client as follows o If the Multimedia Messaging Service is selected by the client and the standalone messaging service is enabled by the service provider via the configuration parameter STANDALONE MSG AUTH as defined in sections A 1 4 3 and A 2 1 of RCC 07 and the client is registered in IMS then Standalone Messaging as defined in section 3 2 of RCC 07 shall be used V2 0 Page 54 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document o Otherwise if supported by the device the client shall use the Multimedia Messaging Service as defined in 3GPP TS 22 140 and 3GPP TS 23 140 4
18. 12 1 2Message Sent confirmation that the message has been correctly accepted by the A Party s network R6 12 1 3Message Delivered Receiving devices have noticed that a message has been received by the device NOTE The Delivery Notification is intended to inform the sender of the message about the delivery status of the message or file transfer Other participants of the Group Chat are not expected to receive the message delivery status R6 12 1 4Message send failed The expected outcome of the operation could not be confirmed by the network in this case Message Sent or Message Delivered status notification has not been received and the device does not attempt to send the message anymore Sending the message may be re triggered manually by the user R6 12 2 OM If the sending device is offline at the time a notification is received notifications shall be stored on the network and forwarded once the sending device is online V2 0 Page 74 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document US6 13 As a user want to see when the other party is currently writing a Group Chat Message R6 13 1 OM The other party shall be able to see an name from contact list or MSISDN is typing notification whenever a new Chat Message is being created US6 14 As auser want to be notified at any time my device receives a new Group Chat Message R6 14 1 R6 14 2
19. 13 3A device capable of making VoLTE calls which is also RCS capable shall operate in RCS VoLTE mode as described in section 2 2 1 of RCC 07 bearing in mind the implications in terms of registration and APN behaviour user story US10 4 For the case of a transition period that a device provides both RCS and VoLTE clients as completely separate implementation the note of the same section becomes relevant R10 13 4 For the requirements of user story US10 5 since RCS IP Voice Call service is not an end to end service service identification is not performed as for end to end services When connecting through a radio technology where RCS IP Voice Calls may be supported see section A 1 14 of RCC 07 NOT include the g gsma rcs ipcall feature tag in the SIP OPTIONS requests and responses for capability exchange as it does not support end to end RCS IP Voice calls A client shall also ignore those capabilities when received Given that on the interconnect end to end RCS IP Voice Calls are not allowed as the operator only offers the option VoIP Breakout the g gsma rcs ipcall feature tags should be filtered out from the OPTIONS request and responses If based on the removed capabilities end to end RCS IP Video Calls were possible and such calls are allowed on the interconnect the g gsma rcs ipvideocallonly feature tag is added to the OPTIONS requests and responses In order to identify that a Voice Call should not be routed end to end over
20. 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document US7 11 As a user want the device to notify me about new incoming files in a similar way to new incoming messages As a user want to be notified in case of incoming positions locations R7 11 1 NOTE R7 11 2 R7 11 3 R7 11 4 R7 11 5 NOTE R7 11 6 R7 11 7 NOTE R7 11 1 OM On receiving a file or preview thumbnail the user shall be notified with graphical and sound elements in a similar way to how the device notifies about incoming messages The standard customization options of the device for incoming notifications shall be available For audio notifications of a new File Transfer request device settings shall prevail Rapid sequence of incoming File Transfer requests and Chat Messages in one Chat Conversation shall be consolidated into one audible notification per Chat Conversation Visual notifications are not affected On selection of the visual notification for a File Transfer the user shall be directed to the respective thumbnail preview in case of auto accept is off or file in case File Transfer auto accept is on within the Chat or Group Chat Conversation The visual notification for an incoming File Transfer shall be permanently removed from the notification centre bar once the thread with the file or thumbnail preview has been opened Independently of whether the user ha
21. 2 3 4 DELIVERY TIMEOUT The DELIVERY TIMEOUT timer defines the timeout for reception of delivery reports for RCS messages and files sent to the B Party There is one DELIVERY TIMEOUT timer used per conversation R4 13 1 8This timer is armed started during an RCS conversation in any of the following situations When sending an RCS chat message or file while there is no other message or file undelivered or unsent When the A Party loses IP connectivity and there are undelivered or pending chat messages or files V2 0 Page 45 of 166 GSM Association Official Document RCC 61 RCS Common Core 1 1 Service Description Document Non confidential R4 13 1 9The DELIVERY TIMEOUT will be stopped when receiving a message or file delivery notification but immediately restarted rearmed if there are still undelivered or pending RCS message s R4 13 1 10When the DELIVERY TIMEOUT expires any undelivered messages shall have their status changed to undelivered and any pending messages shall have their status changed to failed R4 13 1 11 DELIVERY TIMEOUT is only calculated for the first undelivered chat message or file transfer after a delivered one Example A Server B Timeout Starts 1 Delivered Delivery Timeout 2 Delivered Restarts again 2 Delivered 4 Delivery Timeout expires 3 is set to undelivered 4 is set to undelivered Figure 9 DELIVERY TIMEOUT flow diagram V
22. 24 and US6 25 shall be implemented locally on the device R6 37 25 The requirements of user story US6 26 shall be implemented as defined in section 3 4 4 1 3 1 of RCC 07 If the user wants to leave a group chat while it is inactive the client shall restart the Group Chat first as defined in section 3 4 4 1 7 of RCC 07 Subsequent invitations to a Group Chat the user has voluntarily left shall be accepted by the client R6 37 26 The requirements of user stories US6 27 through to US6 32 shall be implemented locally on the device R6 37 27 The requirements of user stories US6 33 through to US6 35 are implemented as defined in section 3 4 4 1 8 of RCC 07 and Messaging for Multi Device page 102 and Operator Messaging page 36 V2 0 Page 83 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document R6 37 28 The specific requirement for handling of locally blocked contacts in user story US6 36 appears to be only a UX function to be implemented locally on the device However with regards to the interactions with Group Chat in the network the client should treat the blocked contacts as regular contacts NOTE Messages sent to the group will also be delivered to the blocked contact 7 File Transfer incl Geolocation Push 7 1 Description File Transfer enables transferring files from one RCS device to one or more RCS devices The main service entry points will b
23. 3 11 1 After a SIM swap the device will enter the state RCS on set up R2 3 12 R2 3 13 R2 3 14 process see also item 3 in next figure RCS in launcher mode This state applies only for those networks that require the user to accept Terms amp Conditions It is considered highly likely that a user that rejected those Terms amp Conditions on the first device start up learns later about RCS and wants to activate it The RCS set up icon shall be visible in this state and if clicked will trigger service activation RCS active RCS is configured and up and running in the device Capabilities are exchanged all entry points enabled and all available RCS services active RCS instance disabled This state is entered by a RCS client if the user has multiple RCS clients on a device and has activated another or if the operator disables the client from the network In this state this RCS client is off all its entry points with the exception of the toggle RCS client switch are disabled and all its user related content is available Chat history files etc Since this RCS client is disconnected in this state no messages can be sent nor capability requests be answered By clicking on the toggle RCS client switch and switching it to ON the RCS client can be re activated At the same time this will trigger the option pop up with link to settings of the active RCS client to deactivate the currently active RCS client Page 14 of 166
24. 3 2 Configuration Parameters The User Stories and Feature Requirements in the previous sections refer to a number of configuration parameters influencing the client behaviour for integrated and seamless messaging Apart from the parameters defined in this section these are defined in sections A 1 4 3 3 and A 1 5 of RCC 07 Service providers need to be able to configure devices for the two operator messaging integration modes defined in this Operator Messaging section A new configuration parameter to control the Common Core messaging UX is defined as follows Configuration Description Parameter parameter usage MESSAGING UX This parameter controls whether the UX for messaging Optional shall be the seamless messaging 0 default value or Parameter the integrated messaging experience 1 NOTE When receiving a provisioning document from a legacy network this parameter is not provided resulting in the default behaviour Table 16 Common Core UX Configuration Parameters The MESSAGING UX parameter will be placed in a new UX MO sub tree defined in this specification f _ FF lt X gt an UX ipVideoCallNonRCS S J A messagingUX Figure 12 UX MO sub tree The associated HTTP configuration XML structure is presented in the table below V2 0 Page 55 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document
25. 4 4 4 5 of RCC 53 and in section 8 of RCC 55 R13 18 4For requirement R13 5 1and R13 5 2 identification of the developer for Second Party apps is covered by the security model defined in RCC 55 For Third Party apps this is up to MNO implementation R13 18 5 For requirement R13 5 3 the following applies e For the Feature Tag uniqueness is ensured by the procedures described in section 5 3 for the second party app and in section 6 3 of RCC 55 e For Developer ID and App ID this is dependent on MNO handling of those Identifiers R13 18 6 Requirements of user story US13 6 is covered by the overall procedures described in RCC 55 R13 18 7 Requirement R13 7 1 for multimedia sessions between the same application is covered e At UNI Level using the multimedia session by the procedures defined in section 3 12 4 2 2 of RCC 07 e At the terminal level through the procedures of section R13 18 8 Requirement R13 7 2 is ensured by procedures of capability discovery of RCC 53 V2 0 Page 141 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document V2 0 R13 18 9 Requirement R13 7 3 is ensured with the same procedures than requirement US13 9 R13 18 10 For requirement R13 8 1 and R13 8 3 the following applies At the U O O NI level If the communication is messaged based using the MSRP protocol the app shall follow the procedures defined in secti
26. A blushing embarrassed face P or P or oP or p or por Stick out tongue op or OP or Op A stick out tongue face Kiss red lips or A kissing face or red lips Shocked surprised O or o or o or O A shocked surprised face Angry er Boh AE ASOT OER An angry face Cool sunglasses B or B or H or h or Bo or BO A face with sunglasses Worried S or Sor S or sor oS A worried face Devilish gt or gt or gt 0 or gt O A devilish face or or 2 or or 0 or 0 Crying or O or O A crying face Laughing or or 0 or O A laughing face ne or or o or O A straight face Angel innocent O or O or o or 0 An innocent face Nerd B or B A nerdish face Sleepy O or Oor o or o A sleepy face Rolling eyes 8 or 8 or 80 or 80 A rolling eyes face Sick ill amp or amp or 0 amp or O amp A sick ill face Se Spaan Ips SS or SS or ss or ss A face with sealed lips Thinking pensive or A pensive face Raised eyebrow sarcastic look A raised eyebrow face or a face with or or 0 or O a sarcastic look Rose flower A rose Cup of coffee 0 A cup of coffee Drink cocktail A cocktail glass Idea light bulb i or A light bulb Page 164 of 166 GSM Association RCS Common Core 1 1 Service Description Document Love struck heart Beer Broken Heart rock on pirate silly applause Penguin Musi
27. Geolocation Push page 84 R12 20 50M An ongoing File Transfer shall be completed even if the call was terminated After completion a notification Shall be displayed that the file is now accessible via the messaging experience R12 20 6 Any file shared during a call shall be available to the user after the call US12 21 As a user while in a voice or video call when receiving a file share request i e user B want to decide whether to accept or reject the incoming invitation based on my operator s configuration for File Transfer R12 21 1 Upon receiving an incoming file on side of user B the File Transfer shall follow the rules described in File Transfer incl Geolocation Push page 84 regarding automatic or manual download of the file R12 21 2 Upon accepting the File Transfer either automatically of manually the file shall be automatically displayed on the user B s screen if the receiving device supports the display of that file type If display of the file type is not supported the user shall be accordingly notified to ensure the simplest user experience how to access the file 12 2 5 Both Exchange messages Exchanging messages during a call is based on the available messaging functionality but is optimised to the ongoing voice or video call situation US12 22 As a user while in a voice or video call want to send chat messages to another user not necessarily the other call party whenever it is possible As a
28. Hold Call Forward Busy CFB Call Forward Unreachable Call Forward No Reply and Conference Call may be offered by a service provider during a RCS IP Voice Call US10 11 As a user want to use DTMF tones during my RCS IP Voice calls R10 11 1 DTMF may be supported within the RCS IP Voice call in both the sender s and receiver s experience US10 12 As a user want to definitely know which call bearer Cellular Wi Fi is used for voice service R10 12 1 The device shall inform the user in a non intrusive way about the Wi Fi voice bearer before making or receiving a voice call 10 3 Technical Information 10 3 1 Overview Voice over LTE VoLTE is a major Technical Enabler for delivering voice call service when in LTE coverage as defined in PRD IR 92 Note that consistently with section 2 2 1 of RCC 07 a device providing both VoLTE ViLTE and RCS can e Follow a single registration target solution for both RCS and VoLTE ViLTE services Note in this configuration the RCS stack works in RCS VoLTE mode e Follow a dual registration approach transition solution where RCS services use a separate registration from the VoLTE ViLTE one in separate instantiations of the stack In this case the RCS stack shall work in RCS CS mode e Follow a single registration for both RCS and VoLTE ViLTE services when in the home network and follow a dual registration approach when roaming For RCS IP Voice call main feature requirements
29. IP and do break out a client shall not include the g gsma rcs ipcall feature tag in the Contact and Accept Contact header fields of the SIP INVITE requests that it sends For an outgoing RCS IP Voice Call a common core 1 0 client shall only include the MMTEL ICSI in the Accept Contact and Contact header fields that is g gsma rcs ipcall and g gsma rcs ipvideocallonly are not included The network shall use this as an indication that the call has to be broken out according to its local policies RCS IP Voice Call shall not be available at NNI level except in the case of a downgrade of a RCS IP Video Call as described in section 3 9 4 of RCC 07 NNI rules are based on CS VoLTE NNI rules Therefore there shall only be a Page 116 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document single NNI for Voice over IMS without differentiation between VoLTE and RCS IP Voice R10 13 5 For requirements of user stories US10 6 and US10 7 following configuration parameters defined in Annex A of RCC 07 and being specific to RCS IP Voice Call shall be considered Configuration Description parameter PROVIDE RCS IP Service Provider Configurable to either 0 i e completely disabled or 1 i e VOICE CALL Wi Fi only for primary devices and any access for secondary devices RCS IP VOICE Service Provider Configurable CALL BREAK OUT Table 28 RCS IP Voice Call con
30. Inthe case user B is anon RCS user with ViLTE during call setup ViLTE capability is to be considered there is a high likelihood for a successful video call upgrade NOTE 3 Likely to succeed means capability or service availability exchange is indicating end to end support Likely to fail means capability or service availability exchange is indicating not available at this time R3 3 4 RCS service information may be presented at other key touch points on the device to indicate RCS communications are enabled V2 0 Page 27 of 166 GSM Association Official Document RCC 61 RCS Common Core 1 1 Service Description Document NOTE V2 0 Non confidential R3 3 5 A contact is deemed to be a RCS user when at least one RCS service capability is discovered and or available for that contact R3 3 6 OM On first RCS device boot up after installation and or set up of the RCS application and after each re configuration of the RCS service the device shall perform an initial setup scan of the contact list and find out which of the contacts are enabled for RCS services R3 3 7 OM Under certain circumstances after the initial setup scan the device shall poll for RCS service capabilities of all contacts or defined subset s of contacts in the contact list in order to promote real time awareness and use of services Any subsequent capability discovery and or service availability checks shall only be made by the device based on the fo
31. R9 5 13 R9 5 14 R9 5 15 R9 5 16 R9 5 17 R9 5 18 R9 5 19 Further improvements to the Messaging for Multi device section such as introduction of synchronisation triggers are expected once the work of the Multi device Messaging Operator Interest Group has been concluded Device Provisioning page 10 for example the CHAT AUTH parameter More specifically Secondary clients and interfaces are handled as per sections 2 11 2 and A 1 10 of RCC 07 In addition when it is required that secondary devices send an SMS or MMS or can receive SMS and MMS as messages as opposed to receiving them only due to synchronisation with the message store procedures defined in RCC 10 shall apply To interwork with SMS MMS the technology shall follow the IM CAP NON RCS parameter If the IM CAP NON RCS parameter is not set by default the device shall use standalone messages When the Chat technology relies on OMA SIMPLE IM and the IM CAP NON RCS is set to 1 it is up to the service provider to realise the SMS and MMS gateway With the adequate configuration devices based on implementations following File Transfer incl Geolocation Push page 84 1 to 1 Chat page 61 Group Chat page 71 and Audio Messaging page 95 will be able to perform requirements R9 2 1 R9 2 3 R9 2 4 and R9 2 5 The network as described in section 9 3 gt Overview will allow forking adding the ability for requirement R9 2 2 User sto
32. TE1 and by endorsements to TE2 Regarding Video orientation requirement US11 12 and R11 12 1 image orientation extension as defined in 2 7 1 2 2 of RCC 07 shall be considered R11 18 15Requirement US11 15 including R11 15 1 shall be implemented as per section 2 3 3 of PRD IR 92 and section 2 3 3 of PRD IR 94 applicable to both Technical Enablers TE1 and with endorsement of TE2 R11 18 16Regarding Supplementary Services requirement US1 1 16 e TE1 shall be implemented as per section 2 3 of PRD IR 92 and section 2 3 of PRD IR 94 e TE2 Availability is up to Service Provider policy and shall be implemented again as per section 2 3 of PRD IR 92 and section 2 3 of PRD IR 94 via endorsements R11 18 17 When receiving a SIP CANCEL request carrying a Reason header field with the protocol set to SIP and the protocol_cause set to 200 a client shall use this information to indicate that RCS the IP Video Call was continued on another device requirement R11 17 3 12 In Call Services 12 1 Description In Call services are available for use during an ongoing voice and or video call between RCS enabled users depending on the capabilities available but in general independent of the actual voice or video call technology With In call Services users achieve a more engaged conversation experience leading to the perception of being closer to each other as talking and sharing becomes more natural and closer to a face to face conver
33. Transfers from Contacts on the local device blacklist R7 17 1 1 shall be ignored by the device R7 17 1 2The user shall not be made aware of any File Transfer attempts from blacklisted Contacts R7 17 1 3No notifications or thumbnail previews shall be displayed R7 17 1 4 n case the user has selected File Transfer Auto Accept as a setting on his device any incoming File Transfer attempts from blacklisted Contacts shall not be auto accepted US7 18 As a user want to administrate File Transfers in Chat and Group Chat Conversations intuitively R7 18 1 The user shall have the option to delete File Transfer events outgoing or incoming from a Chat or Group Chat Conversation R7 18 1 1Deleting a single File Transfer directly from the chat conversation R7 18 1 2Delete multiple File Transfer events with or without other associated events in the conversation such as Chat messages R7 18 1 3Deleting a File Transfer from the Chat or Group Chat Conversation shall delete the entry in the conversation thread and the Operator Store e g CMS R7 18 2 lf received or sent files are automatically stored on a device or online repository e g an RCS gallery on the device picture gallery then deleting the File Transfer events from the conversation thread does not automatically delete any files from this repository In case the user permanently wants to delete this content separate user action is required as per individual device operat
34. Unreachable and Call Forward No Reply may be offered by a service provider during an IP video call NOTE Supplementary services shall be aligned across voice and video call types US11 17 As a user want to see my initiated and received IP video calls in my call logs similar to any other voice call R11 17 1 The IP video call must be displayed in the single voice AND video call log interface per contact or global call log R11 17 2 n that single log of the user s device an IP video call shall be differentiated with a specific visual reference from a standard voice call and or from an enriched voice call i e with content sharing that has taken place during the call V2 0 Page 121 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document R11 17 3 Similar to voice call events initial video call events i e not added in call shall be differentiated between answered and unanswered video calls R11 17 4The B party shall be informed of any video calls they have missed The notification shall clearly show that the missed call is an IP video call 11 3 Technical Information 11 3 1 Overview The IP Video Call service shall be realised based on two main Technical Enablers o TE1 ViLTE Technical Enabler as defined in PRD IR 94 and o TE2 RCS IP video call service as described in sections 2 2 1 2 7 1 2 2 and 3 9 of RCC 07 Note the two implementations are ful
35. based 3 party services can be accessed over Wi Fi if offered by the 3 party if Wi Fi capability is enabled on the device the device is attached to a public or private Wi Fi access point and the Wi Fi access point has connection to the Internet US15 4 As an operator want to use various technologies for the production of operator communication services R15 4 1 For production of operator voice video and messaging services the following V2 0 technologies bearers shall be considered in scope R15 4 1 1CS call over 2G network R15 4 1 2CS call over 3G network R15 4 1 3VoLTE call over 4G network R15 4 1 4RCS IP call over Wi Fi bearer R15 4 1 5SMS over 2G and 3G network R15 4 1 61R 92 SMS over 4G network R15 4 1 7MMS over 2G and 3G network R15 4 1 8MMS over 4G network R15 4 1 9RCS Chat over 2G 3G 4G network or Wi Fi bearer R15 4 1 10RCS File Transfer over 2G 3G 4G network or Wi Fi bearer R15 4 1 11RCS In Call services over 3G 4G networks or Wi Fi bearer Page 151 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document R15 4 1 12RCS IP Video Call over 3G 4G network or Wi Fi bearer R15 4 1 131R 94 ViLTE over 4G network R15 4 1 14Operator Provisioning over 2G 3G 4G networks or Wi Fi bearer R15 4 2 The availability of the services listed in requirement R15 4 1 shall be configurable on a per operator basis as per the table below
36. been delivered to the B Party device R5 2 1 4 Message Displayed Confirmation the message was displayed on the receiving device technical confirmation that message was read by the recipient R5 2 1 5 Message send failed The expected outcome of the operation could not be confirmed by the network in this case Message Sent or Message Delivered status notification has not been received and the device does not attempt to send the message anymore Sending the message may be re triggered manually by the user R5 2 2 OM If the sending device is offline at the time a notification is received notifications shall be stored on the network and forwarded once the sending device is online US5 3 As a user want to include smilies into my Chat Messages NOTE Smilies are small graphical elements that can express mood fun or icons to explain a thing or a status in a graphical easy to use and understand manner Example for smilies are and R5 3 1 It shall be possible to add Emoji when creating a chat message by adding from a selection of graphical elements in the chat application NOTE Standards for conversion of text strings to Emoji are described in Annex Emoticon conversion table page 164 R5 3 2 It shall be possible to add the basic Emoticons when creating a chat message by typing in the respective text string separated by blank spaces e g converts to or typing in the respective text string without blank space
37. calls over an IP bearer which can be delivered via Voice over LTE call VoLTE as defined in GSMA permanent reference document IR 92 or via RCS IP Voice Call as per sections 2 2 1 and 3 8 of RCC 07 Both calling technologies are exclusive to each other and cannot be operated in parallel on one device RCS IP Voice Call in particular replaces one or both legs of a CS Call or VoLTE Call in order to extend voice calling to situations where neither of these two voice bearers is available An RCS IP Voice Call leg shall break in out to a CS or VoLTE network as required Therefore RCS IP Voice Call allows voice calling capabilities for RCS users either on secondary devices e g tablet PC IP TV etc or on primary devices i e mobile phones when cellular bearer is not available but data connectivity is available over Wi Fi RCS IP Voice Call has to be activated and configured by the individual operator during the RCS provisioning process of the device This section describes the User Stories and Service Requirements for the core IP Voice Call service and all features around that core 10 2 User Stories and Feature Requirements US10 1 As a user i e user A want to make and receive voice calls with my 4G supporting primary device while my device is still registered on a 4G network bearer R10 1 1 Voice over LTE calls shall be supported on primary devices supporting 4G data US10 2 As a user I i e user A want to make and
38. can be realised only for TE1 following section 2 6 1 1 2 of RCC 07 Requirement R3 3 8 1 which shall follow TE2 Requirement R3 3 9 is implemented locally on the device following error codes handling defined in 2 6 1 1 and 2 6 2 1 RCC 07 for TE1 and TE2 implementations Requirement R3 3 10 shall set the RCS state set to 1 in the configuration request and follow client codes 2 3 3 2 1 and procedures defined in RCC 07 Requirement R3 3 11 is implemented locally on the device following 2 6 3 RCC 07 and POLLING PERIOD set to 0 as per A 1 11 RCC 07 or following 2 6 2 1 RCC 07 for inconclusive results Requirements R3 3 12 and R3 3 13 shall be implemented locally on the device Page 35 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document 4 Operator Messaging 4 1 Description Operator Messaging integrates various Messaging Services SMS MMS 1 to 1 Chat Group Chat File Transfer Geolocation Push and Audio Messaging to one single conversational view for the end consumer This chapter is structured into two main parts the representation of Operator Messaging on the device and the client logic that proposes decides the Messaging Service based on availability of services and bearers on both sides of the conversation to convey the message or file In some configurations the proposed Messaging Service can be overridden at any time by the end consumer e R
39. contact card R6 5 1 R6 5 2 R6 5 3 R6 5 4 NOTE R6 5 5 V2 0 OM Any participant in a Group Chat Conversation shall be able to see a list of participants at any point in time OM If the sender of a Group Chat Message is in my contact list the MSISDN shall be replaced with the senders name on the contact list in any representations where the message sender is represented OM If the sender of a Chat Message is not in my contact list the MSISDN shall be replaced with the sender s RCS Alias name if available OM In case the Alias is being used to represent the sender s identity the device UI shall use appropriate means to indicate that the Alias name is unverified information The Alias as specified in RCS 5 2 standard is being created by the message sender and could be set to any possible name the real name of the person or a nickname or in extreme cases in an attempt of identity spoofing the sender could try to pretend a false identity OM If neither Contact name nor RCS Alias is available a participating contact shall be represented with the MSISDN in the list of Group Chat participants Page 72 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document R6 5 6 OM In the case where new Group Chat participants join the Group Chat all other Group Chat participants shall be notified with graphical elements inside the Group Chat Conversation only
40. conversion table page 164 R6 10 2 It shall be possible to add the basic Emoticons when creating a chat message by typing in the respective text string separated by blank spaces e g converts to or typing in the respective text string without blank spaces if the string is the only characters of the message content NOTE The basic set of Emoticons is listed in the Annex Emoticon conversion table page 164 R6 10 3 OM Emoji shall be interpreted as detailed in the conversion table in the Annex of this document The graphical elements that are used may vary from vendor to vendor but the conveyed meaning must not be changed R6 10 4 OM Emoticons from the basic set of Emoticons which are received in Chat Messages shall be converted to graphics if they were separated by blank spaces in messages e g converts to or without the blank spaces if the emoticon string is the only characters of the message content US6 17 As a user don t want to feel restricted by Group Chat Message size limits R6 11 1 OM Group Chat Messages incoming and outgoing shall allow to send and receive at least 999 characters NOTE Operator defined parameter US6 12 As a user want to see the status of my sent Group Chat Messages R6 12 1 OM For A Party the following message states shall be indicated to the user R6 12 1 1Message Pending Transfer of the Chat Message in progress e g queuing on device R6
41. described in US2 10 R2 11 14 For requirement R2 4 3 as defined the configuration shall be applied and the service shall be activated when the user presses the Accept button moving to another screen shall be considered equivalent with this accept button action R2 11 15 The user consent after activation of the service described in user story US2 6 shall be realised through the mechanism End User Confirmation Request mechanism described in section 3 1 of RCC 15 This mechanism shall be supported by the RCS clients and may be used upon service provider discretion No specific handling apart from the normal processing of End User Confirmation Requests is thus assumed to be provided on the device R2 11 16As described in section 3 1 of RCC 15 the End User Confirmation Request mechanism supports requirements R2 5 1 R2 5 2 R2 5 3 and R2 5 4 For requirement R2 5 2 in the case when one button is required the End User Notification Request described in section 3 1 3 of RCC 15 shall be used For a message requiring two buttons the End User Confirmation Request and Response described in section 3 1 1 and 3 1 2 of RCC 15 respectively shall be used R2 11 17 Requirement R2 5 5 shall be implemented locally on the device R2 11 18For requirements R2 5 6 and R2 5 7 the network shall disable the RCS client by triggering a client reconfiguration using the procedure defined in R2 11 24 and R2 11 25 returning a HTTP configuration response
42. duration the duration can be unlimited e At the network level triggering of the revocation procedures in the network is dependent on the MNO s policy on revocation procedures R13 18 22 Security model e Devices exposing API shall restrict applications from accessing the RCS infrastructure based on the security model defined in RCC 55 and on the Service Provider s policy provided through provisioning see Differences to previous versions RCS Common Core 1 1 is a maintenance update that provides further clarification to existing requirements The technical information has also been updated to align with RCS 5 3 see section 1 5 of RCC 07 13 3 3 Summary of Changes e Device Provisioning o Alignment with RCC 14 and RCC 15 e Capability Discovery and Service Availability o Clarification on the behaviour of the CAPABILITY VALIDITY timer see requirement R3 3 7 5 6 e Operator Messaging V2 0 Page 143 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document o Clarification to the Integrated Messaging requirements for proposed message selection see section 4 2 1 1 o Clarification on the DELIVERY TIMEOUT behaviour and technology selection logic for Integrated Messaging variant 1 see section 4 2 3 e One to One Chat o Additional requirements for handling unseen messages and files see requirements for user story US5 13 e Group Chat o Additional requirement introd
43. happen over cellular or non cellular networks V2 0 Page 11 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document 2 2 2 2 1 User Stories and Feature Requirements Configuration of the user s primary device by requesting user identity US2 1 As an operator want my RCS users to verify their identity before they use the RCS service R2 1 1 When automatic identification of the user is not possible the user shall be prompted to provide manually type in the MSISDN To do so a pop up shall be displayed R2 1 2 To ensure validity of the provided MSISDN a verification process shall take place R2 1 2 1 A silent SMS with a password is sent to the device R2 1 2 2 This SMS shall be intercepted by the RCS provisioning process and verified R2 1 3 In case the verification process has been completed successfully the provisioning process shall be completed without any further user interaction R2 1 4 If the SMS takes too long or is never received e g because the network does not deliver the SMS properly or the user provided a wrong MSISDN the user shall be presented with a screen informing them that the process is taking longer than expected and cannot be completed at this stage R2 1 5 For this case the user shall be informed about the previously given MSISDN so that the user can amend it if necessary and shall be provided with means to retry NOTE This
44. location or position to the other contact while in a call US12 23 As a user while in a voice or video call i e user A want to send my location or a position from my in call screen to the other participant of the call i e user B whenever it is possible As a user while in a voice or video call i e user B want to receive A s location or a position in my in call screen from the other participant of the call i e user A whenever it is possible R12 23 1OM Location Push shall be possible during an ongoing voice CS VoLTE RCS IP Voice Call or video ViLTE RCS IP Video Call call while the call shall continue seamlessly on the same bearer R12 23 2 OM During such call user A can select directly from the in call screen to send the current location or a position to user B which is automatically accepted based on File Transfer configuration and displayed on user B s screen R12 23 3 OM In case the underlying voice or video call is terminated a Location Push may be terminated but could be received via the messaging experience of the receiver instead R12 23 4 Any Location Push during a call shall be available to the user after the call 12 3 Technical Information 12 3 1 Overview Based on the requirements the in call services are constituted of the following main services e Video share sharing video during a call Implemented via the RCS Video Share service as described in section 2 7 1 2 an
45. messages R12 24 23 The realisation for requirements for user story US12 22 R12 22 1 R12 22 2 and R12 22 3 is covered in section 12 3 exchange messages during a call NOTE It is required for a client device implementation to be able to identify whether a message is received from the other party in a call to if so present the File Transfer within the call window instead the messaging application If the conversation continues after the call is terminated it is expected that the exchange takes place within the messaging application meaning the exchanges that took place during the call are part of the messaging history R12 24 24 Requirements R12 22 4 R12 22 5 and R12 22 6 shall be implemented locally in the device 12 3 2 5 Location Push R12 24 25 The realisation for requirements of user story US12 23 are covered in section 12 3 geolocation push e Note that it is required for a client device implementation to be able to identify whether a location push is received from the other party in a call to if so present the File Transfer within the call window instead the messaging application e If the conversation continues after the call is terminated it is expected that the exchange takes place within the messaging application meaning the exchanges that took place during the call are part of the messaging history R12 24 26 Requirement R12 23 2 and R12 23 4 shall be implemented locally in the device 13 API Extensions 13 1 De
46. of my chosen connectivity conditions R15 1 1 Voice and video services shall be available whenever the device is registered to a cellular network or a Wi Fi connection is available NOTE V2 0 The availability of voice and video services offer over Wi Fi is at the discretion of the operator Page 149 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document R15 1 2 NOTE R15 1 3 R15 1 4 R15 1 5 R15 1 6 R15 1 7 The operator shall be able to zero rate data traffic which is induced by voice and video calling and meter minutes instead Signalling that is used for production of operator voice and video services shall be in the background and hidden from the user i e also not metered Operator voice services shall be available over the cellular network irrespectively of the setting of the cellular data switch Operator video services shall be based on operator configuration see R15 4 2 be available over the cellular network when the cellular data switch is switched off In domestic case and roaming the operator tariff scheme for voice and video services applies Operator voice and video services over cellular shall be disabled by the device in flight mode Voice and video calls over Wi Fi may be possible if offered by the operator and allowed by the airline see note to 15 1 1 Wi Fi based operator voice as described in RCS 5 2 standard shall
47. of the message US6 9 As a user want to send text Chat Messages to my Group Chat participants even when they re temporarily offline e g device switched off expect them to receive these Chat Messages when they come online again R6 9 1 OM In case any participant in a Group Chat Conversation is currently not registered on the RCS service remark offline any message s or updates to the list of Group Chat participants shall be delivered once the user is back registered on RCS remark online R6 9 2 The operator shall be able to set the storage duration for store amp forward cases deferred messaging based on individual operator parameters NOTE The parameters may be aligned on local level as the terminating network storage time has an impact on the sending network user s experience US6 10 As auser want to include smileys into my Chat Messages NOTE Smileys are small graphical elements that can express mood fun or icons to explain a thing or a status in a graphical easy to use and understand manner Example for smileys are ande V2 0 Page 73 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document R6 10 1 It shall be possible to add Emoji when creating a chat message by adding from a selection of graphical elements in the chat application NOTE Standards for conversion of text strings to Emoji are described in the Annex Emoticon
48. option to resize the image to smaller file size in order to save memory network load and transfer time Resize means changing the picture resolution NOTE In most cases users are aware of the use of the picture on the receiver side for instance whether it shall be displayed on small screens only or whether it may be printed on large scale This feature provides the user with an option to adapt to these cases US12 18 As a user when receiving an image share request i e user B want to decide whether to j Decline the incoming image share request and continue with a plain voice call k Accept the incoming image share request R12 18 1 OM The receiver shall be able to accept or reject an incoming image share no auto accept The sender shall be notified accordingly about the selection of the receiver R12 18 2 OM Upon acceptance the picture is transferred to the receiver R12 18 3 Once the transfer of the image is completed the received picture shall be displayed with minimal user interaction on the receiver s screen R12 18 4When the underlying call is terminated for any reason the image share shall stop and the receiver shall no longer have access to the image US12 19 As auser accepting an incoming image share i e user B want the incoming voice automatically on a connected headset If there is no headset connected then play the voice on my external loudspeaker R12 19 1 When an incoming image share is acce
49. possibly have been exchanged before the participant has joined the Group Chat US6 20 As a user want to exchange multi media content e g but not limited to take an instant picture from camera and send from within the chat in my Group Chat Conversations NOTE Details on multi media content are covered by File Transfer incl Geolocation Push page 84 R6 20 1 The user shall be able to select and send Multi Media elements in Group Chat Conversations NOTE Details on multi media content share are covered by File Transfer incl Geolocation Push page 84 V2 0 Page 76 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document R6 20 2 OM The user shall be able to receive Multi Media elements in Group Chat Conversations NOTE Details on multi media content share are covered by File Transfer incl Geolocation Push page 84 US6 21 As a user want to view my sent and received Group Chat Messages in a time based order R6 21 1 OM All messages exchanged within the same Group Chat Conversation shall be threaded in the same group chat thread in timely order R6 21 2 OM The order of messages shall be in line with the order messages have been sent and received on the device R6 21 3 Incoming and outgoing messages shall be displayed interlaced R6 21 4 Outgoing messages shall be inserted into the Group Chat Conversation thread as they have been se
50. procedure can be attempted a maximum of ten times after which RCS is deactivated and the user shall be informed of how to attempt to reactivate RCS later US2 2 Asa user want to seamlessly use RCS services after bought a new RCS enabled smartphone As a user want to start using my RCS services independently of the connectivity status Wi Fi or cellular coverage of my device while setting up the new device or download an RCS client NOTE It is an accepted restriction that device provisioning does not happen in case V2 0 there is no data connectivity at all R2 2 1 When the user activates RCS over a network that allows automatic authentication then provisioning of the service and configuration of the device shall be done without any user interaction However there are three exceptions covered in R2 4 1 R2 5 1 and R2 5 1 R2 2 2 n any case where the network hasn t been able to identify the user automatically the device will enter into the process which describes the configuration of the user s device by requesting the identity of the user via manual submission of the MSISDN Page 12 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document 2 2 2 Downloadable RCS application Multiple RCS instances US2 3 As a user want to download RCS applications and use them without any additional manual configuration R2 3 1 R2 3 2 R2 3 3 R2 3 4 R2
51. roaming etc shall apply The operator RCS Messaging Services shall be available whenever the device is connected to a cellular network or a Wi Fi connection is available Page 150 of 166 GSM Association Non confidential Official Doc NOTE ument RCC 61 RCS Common Core 1 1 Service Description Document Wi Fi service offer is at the discretion of the operator R15 2 9 The operator may apply as part of the terms and conditions a Fair Use Policy for Data Consumption of RCS Services on Home Network which shall Not apply for usage on visited networks e g in case of national or international roaming US15 3 As a user want to use 3 party services on my smartphone device or browse the Internet or an Intranet R15 3 1 The operator Internet Access service shall be available whenever the device is registered to a cellular network and the user is enabled by the operator to use cellular data services R15 3 2 The device may offer Internet access services using a Wi Fi connection as well The user shall be free to select which access service shall be used for connection to Internet services at any point in time R15 3 3 Signalling that is required for the production of Internet based 3 party services is not separated from any user data and counted as such as user data R15 3 4 Internet based 3 party services are not available over cellular access when the cellular data switch is switched off R15 3 5 Internet
52. sent message DELIVERY TIMEOUT during an active conversation when the B Party is an Operator Messaging user Integrated Messaging option 1 or File Transfer option 1 Page 28 of 166 GSM Association Official Document RCC 61 RCS Common Core 1 1 Service Description Document V2 0 R3 3 7 5 6 R3 3 7 5 7 R3 3 7 5 8 Non confidential When the A Party has just come online during an ongoing conversation and the current messaging services is XMS Integrated Messaging option 1 or File Transfer option 1 When initiating a voice or video call with contact During a voice or a video call with a known RCS contact R3 3 7 6 The CAPABILITY VALIDITY timer shall be reset every time a chat message or File Transfer event is received and when a delivery notification for a sent message is received R3 3 7 7 OM The operator shall have the ability to limit the impact of capability and availability checks based on the following R3 3 7 7 1 R3 3 7 7 2 R3 3 7 7 3 R3 3 7 7 4 R3 3 7 7 5 An operator defined minimum interval duration shall exist between two queries sent to the same RCS contact CAPABILITY VALIDITY An operator defined minimum interval duration shall exist between two queries sent to the same non RCS contact An operator defined telephone number prefix setting RCS applications shall use known and valid contact capability or service availability information which is stored locally on the device i e cached
53. session when that event occurred In this case it shall be clear to the user that they are able to download and access older events on that device or interface if desired and an option shall be made available to the user to do so When File Transfer content is synchronised with devices and interfaces which were inactive for its associated session the files themselves shall only be downloaded automatically in full when the Auto Accept parameter value is set to on When the Auto Accept parameter is set to off File Transfer events shall be represented by their thumbnails or preview icons which the user can select in order to trigger the download of that particular file on that device ot interface A download all option may be available to trigger the download of all the content of the displayed conversation history on that device if desired OM an RCS user with multiple RCS enabled devices and or interfaces shall have all their events messages content notifications associated with R9 3 4 available on all their registered and connected devices and interfaces as soon as possible OM an RCS user with multiple RCS enabled devices and or interfaces shall receive notifications of new incoming events belonging to services listed in R9 3 4 on all their RCS enabled devices and interfaces if the incoming event is not part of an existing conversation or session OM An RCS user with multiple RCS enabled devices and or inter
54. storage duration for messages on the Common Message Store based on individual operator parameters R5 19 3 Incase the operator deletes messages from the Common Message Store e g for capacity limitation these messages shall not be deleted from local consumer equipment US5 20 As a user want my device always be in sync with the Chat Messages stored in the Common Message Store even in case of multiple devices As a user want to send Chat Messages from secondary devices R5 20 1 1 to 1 Chat shall support Multi Device Usage V2 0 Page 66 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document NOTE Details on secondary device use will be described in Messaging for Multi Device page 102 US5 21 As a user want to restore my Conversations from the Common Message Store e g but not limited to after wiping device or purchasing a new device R5 21 1 The user shall have the option to restore Conversations from the Common Message Store e g but not limited to in case of handset replacement or automated local memory removal of messages on device to free up memory space US5 22 As a user want to delete complete Conversations As a user want to select and delete single and multiple nonadjacent chat messages in a chat thread R5 22 1 The user shall have the option to delete a single Chat Message from a Conversation R5 22 2 The user shall have the option t
55. the chronological order e After the client has synchronized with the Common Message Store successfully then messages shall be sorted in accordance with the time indicated in the CPIM DateTime header value received with message from the Common Message Store R5 26 12 The requirement R5 11 3 shall be implemented as defined in section 3 3 4 1 10 of RCC 07 R5 26 13The requirements of user story US5 12 shall be implemented locally on the device R5 26 14The requirements of user story US5 13 shall be implemented locally on the device R5 26 15 The user alias defined in user story US5 14 for addresses which do not match a contact shall be implemented as defined in section 2 5 3 3 of RCC 07 R5 26 16 For the realization of requirements of user story US5 15 the client shall enforce the max message size for sending messages as defined by the configuration parameter MAX SIZE 1 to 1 IM defined in section A 1 4 3 of RCC 07 It is required for service providers to set the value to 999 or more R5 26 17 For the requirements of user story File Transfer will be used as defined in File Transfer incl Geolocation Push page 84 For the interactions with the 1 to 1 Chat message service the requirements of section 3 5 2 of RCC 07 apply R5 26 18The requirements of user stories US5 17 and US5 18 shall be implemented locally on the device R5 26 19The requirements of user stories US5 19 US5 20 and US5 21 are implemented as defined in M
56. the Audio Message may be presented to the sender for playback and or sending Audio Messaging shall support status notification per individual Audio Message sender side R8 1 10 1 Audio Message transfer Pending waiting to transfer the Audio Message to the network e g queuing on device R8 1 10 2Audio Message transfer in progress progress indicator that displays V2 0 the transfer progress of the Audio Message transmission from sending device to the network Page 96 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document R8 1 10 3Cancelled presented when the sender has chosen to cancel the Audio Message sending during the transfer process R8 1 10 4O0M Audio Message delivered transmission of the underlying File Transfer request has been successfully completed to the receiving network NOTE On receiving side the Audio Message is either ready for download or has been downloaded R8 1 10 5Audio Message downloaded either an automatic or user initiated download of the Audio Message is complete R8 1 10 6Audio Message transfer failed the sending device does not attempt to send the file to the network anymore however sending may be re triggered manually by the user R8 1 10 7 OM If the sending device is offline at the time a notification is delivered notifications shall be stored on the network and forwarded once the sending device is onlin
57. the same time chatting to Bob using my tablet R9 4 1 OM It shall be possible for an RCS user A with multiple connected RCS enabled devices and or interfaces to have multiple conversations with different Contacts at the same time from the same or from different devices interfaces NOTE A device or interface is active for a specific session not for a generic RCS service V2 0 Page 106 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document 9 3 Technical Information 9 3 1 Overview R9 5 1 Provisioning e The Primary device shall be provisioned as per Differences to previous versions RCS Common Core 1 1 is a maintenance update that provides further clarification to existing requirements The technical information has also been updated to align with RCS 5 3 see section 1 5 of RCC 07 9 3 2 Summary of Changes e Device Provisioning o Alignment with RCC 14 and RCC 15 e Capability Discovery and Service Availability o Clarification on the behaviour of the CAPABILITY VALIDITY timer see requirement R3 3 7 5 6 e Operator Messaging o Clarification to the Integrated Messaging requirements for proposed message selection see section 4 2 1 1 o Clarification on the DELIVERY TIMEOUT behaviour and technology selection logic for Integrated Messaging variant 1 see section 4 2 3 e One to One Chat o Additional requirements for handling unseen messages and files see req
58. to be able to change the discoverability setting for specific applications via RCS Settings Apps may also provide this option within the application UI US13 12 As a user want to be able to trigger interaction with a contact having the same enabled RCS app from the address book contact card or from within the app US13 13 As a user when uninstall an RCS enabled app it is no longer notified to other RCS enabled app users in Capability exchange US13 14 As an operator want to be able to find out how many instances of each RCS enabled app have registered their capability with my network via the Feature tag US13 15 As a user when install an app enabled by RCS I want to be informed that this app will use the RCS services through the API US13 16 As an operator want to be able to introduce a network element to measure the volume of data traffic triggered by each specific RCS enabled app on my network identified by the app s Feature Tag s US13 17 As an operator can identify the developer owner of an app from the app s Feature Tag s US13 18 As an operator can block traffic and withdraw access for a specific service or application making use of the RCS APIs identified by the specific Feature Tags Blocking an app which sends traffic chat or File Transfers etc to the native RCS UI App to Native messaging will not affect the user s ability to send such traffic from other apps or from their native RCS UI
59. user while in a voice or video call want to receive chat messages from another user not necessarily the other call party whenever it is possible R12 22 1 OM Sending and receiving messages from to any other RCS enabled user shall be possible during an ongoing voice CS VoLTE RCS IP Voice Call or video VILTE RCS IP Video Call call while the call shall continue seamlessly on the same bearer NOTE This includes the case where other in call services are also in progress R12 22 2 When sending messages the RCS application shall follow the logic described in Operator Messaging page 36 R12 22 3 Message notifications shall be clearly displayed or announced to indicate the arrival of the new message and to facilitate access to the message V2 0 Page 131 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document R12 22 4 Sending messages to the other participant of the call shall be possible from the in call screen R12 22 5 Messages received from the other participant of the call shall be clearly displayed and it shall be easy to continue the messaging conversation in parallel to the audio or video call R12 22 6 Any chat during a call shall be available to the user after the call similar to the experience of Chat outside a call as described in 1 to 1 Chat page 61 12 2 6 Location Push Location Push as In Call Service describes the functionality to allow sending a
60. value com vendor product MyRCSSettingsActivity gt lt RCS client shall define a settings property such that it can be open by third party applications using an intent which action string corresponds to the meta data value defined above gt lt activity android name MyRCSSettingsActivity gt lt intent filter gt lt action android name com vendor product MyRCSSettingsActivity gt lt category android name android intent category DEFAULT gt lt intent filter gt lt activity gt Table 3 Android meta data usage R2 11 6 4Every RCS client shall define a publicly readable Shared Preferences using the name pckgname gsma joyn preferences where pckgname parameter shall be replaced with clients unique package name of the application no two applications can have the same package name on the Android market Client shall add this to the manifest as a meta data lt meta data android name gsma joyn preferences android value pckgname gsma joyn preferences gt R2 11 6 5The shared preferences shall be created using the RCS client application context using the mode MODE_WORLD_READABLE R2 11 6 6The shared preferences shall contain a Boolean property named gsma joyn enablea R2 11 6 7This property can have two values e True It will mean that the RCS client is enabled user switch in settings set to ON and the application has been provisioned successfully e False default value It wil
61. via device configuration as defined in section 2 13 1 5 of RCC 07 IMAP sessions are encrypted by use of TLS as defined in section 2 13 1 5 of RCC 07 R14 4 5 5The authentication method for HTTP XCAP transactions with the XDMS V2 0 is either based either based on AKA based on the Generic Bootstrapping Architecture GBA 1 or digest authentication 2 with the IMS credentials received by the client via device configuration or network Page 147 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document V2 0 based user identification 3 as defined in section 2 13 1 4 of RCC 07 The encryption of HTTP XCAP is based on TLS as defined in section 2 8 of RCC 07 R14 4 5 6For MSRP transaction no additional user identification is applied The MRSP transactions rely on the user identity that has been authenticated in the related SIP registration of session The encryption of MSRP signalling is determined by client configuration as defined in section 2 8 of RCC 07 and 2 2 2 2 of RCC 15 R14 4 5 7For RTP media streams no additional user identification is applied The RTP transactions rely on the user identity that has been authenticated in the related SIP registration of session The encryption of RTP streams is determined by client configuration as defined in section 2 8 of RCC 07 and 2 2 2 2 of RCC 15 R14 4 6 For the requirements in user story US14 1 to minim
62. visible and selectable In the case when the capability exchange fails the service entry point colour will change and the service entry point will become unselectable 1 The Video service entry point will be conditionally visible and always selectable In the case when the capability exchange is successful the service entry point is visible and selectable In the case when the capability exchange fails the service entry point will change and remain selectable NOTE The VIDEO UX behaviour is valid for any phone number NOTE Successful Capability exchange includes video Table 4 Video Service Entry Point UX Configuration Parameter V2 0 Page 31 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document A new configuration parameter to control the display and selectability of the In Call Service Entry UX is defined as follows Configuration Description Parameter parameter usage INCALL UX This parameter controls the visibility and Optional selectability of the UX service entry point s for In Parameter call services 0 default value 0 The In Call service entry point will be conditionally visible and conditionally selectable In the case when the In call service capability exchange is successful the service entry point is visible and selectable In the case when the In call service capability exchange fails the In call serv
63. when connected on Wi Fi When connected on cellular and when using the IMS APN RCS messaging shall be available as per SMSOIP DATA OFF described in R15 5 21 When RCS is using the internet APN TE2 RCS messaging shall be available as per section 2 9 1 4 of RCC 07 if data is on RCS messaging shall be available If data is off and RCS is using the internet APN the RCSE ONLY APN shall be used if configured and RCS Messaging shall be available on cellular networks if allowed as per R15 5 21 If no value is configured for the RCSE ONLY APN configuration parameter RCS Messaging shall not be available on cellular networks in those circumstances R15 5 18For requirement R15 2 9 a Fair Use Policy in the home network shall be possible as a consequence of R15 5 9 The operator can differentiate on whether the user is in the home or visited network based on the P Access Network Info header field in the SIP signalling R15 5 19For requirement R15 3 1 R15 3 2 R15 3 4 and R15 3 5 this shall be implemented locally on the device R15 5 20 For requirement R15 3 3 signalling generated by a 3 party service cannot be differentiated from user traffic of that 3 party service because the signalling is defined in a proprietary way by the 3 party without involvement of the operator AS a consequence such signalling shall be considered as regular data traffic R15 5 21 Requirements R15 4 1 and R15 4 2 shall be realised according t section 2 9 1 5 and 2
64. with the RCS DISABLED STATE configuration parameter set to 2 ensuring that the RCS touch points remain available as described in section 2 3 3 2 of RCC 07 R2 11 19 For requirement R2 5 8 RCC 07 does not impose restrictions on the use of the End User Confirmation request mechanism Further messages can thus be sent at any point in time including immediately after a previous one R2 11 20As described in section 2 2 5 of an operator can choose to fall back to the SMS based authentication mechanism used on networks where automatic identification is not possible This allows in combination with the mechanism described in section 2 3 2 and 2 3 5 of to handle that SMS in a manner that is not transparent to the user thereby supporting the requirement R2 6 1 This same non transparent handling of the SMS can be used to realise this requirement on networks where automatic identification is not possible R2 11 21 Requirement R2 7 1 shall be implemented locally on the device by making the contents of any received User Message and non volatile End User Confirmation Request available for consultation by the user at a later time This consultation shall not require the user to provide a response to the request Page 24 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document R2 11 22 lf the subscriber cannot be provisioned due to operator policy i e a permanent unavailability as de
65. 1 1 FT Auto Accept I O default value set to l R16 9 1 2 FT Auto Accept while roaming I O default value set to O US16 10 As a user want to be able to control the image resizing options in RCS File Transfer R16 10 1 The user shall have to option to set one of the following selections R16 10 1 1 always resize a selected option which is then stored as default value R16 10 1 2 always ask R16 10 1 3 never resize R16 10 2 The default setting shall be always ask R16 10 3 For downscaling pictures the following requirements shall apply R16 10 3 1The size of the image shall be reduced using following algorithm Scale both dimensions by the same factor F same for width and height so the aspect ratio is maintained Compress as JPG with q 75 Compare the new image size with the original and only offer the possibility to resize if the resulting file is smaller than the original one R16 10 3 2The default scale factor F for the image shall be F min 1280 w 1280 h 1 0 It shall be noted the w width and the h height shall be used in pixels for the calculation R16 10 3 3lf the factor F is 1 the original image shall be transferred US16 11 As a user want to be able to control the video resizing options in RCS File Transfer R16 11 1 The user shall have to option to set one of the following selections R16 11 1 17 Always resize to a selected option which is then stored as default value R16 11 1 2Always ask V2 0 Page 1
66. 1 OM In case during an ongoing IP video call one user moves out of LTE coverage the transmission of the video media part of the IP Video Call should be maintained if network conditions allow US11 8 As users in an IP video call with insufficient bandwidth want to be made aware of when the video stream is interrupted until bandwidth is improved and the video transmission is continued R11 8 1 OM When connectivity during an IP Video Call is insufficient to deliver a decent video stream the video stream displayed to the user shall be interrupted and a visual indication shall be provided that connectivity is insufficient and the video continues when connectivity conditions are improved NOTE Preferably a visual icon is used instead of an error message US11 9 As users in an IP video call we want to continue the call as voice call only in case video cannot be maintained for any reason anymore so that the call does not drop entirely R11 9 1 OM Incase during an ongoing IP video call one user loses the ability to transmit video completely i e loss of data the call should continue as voice call without video R11 9 1 10M If it is not possible to continue the call as a best effort quality video call or as b voice call a call may eventually drop US11 10 As users in an IP video call we want to stop and restart transmitting the camera view at any point during the call without interrupting the call i e audio is maintained during
67. 1 is a maintenance update that provides further clarification to existing requirements The technical information has also been updated to align with RCS 5 3 see section 1 5 of RCC 07 9 3 4 V2 0 Summary of Changes Device Provisioning o Alignment with RCC 14 and RCC 15 Capability Discovery and Service Availability o Clarification on the behaviour of the CAPABILITY VALIDITY timer see requirement R3 3 7 5 6 Operator Messaging o Clarification to the Integrated Messaging requirements for proposed message selection see section 4 2 1 1 o Clarification on the DELIVERY TIMEOUT behaviour and technology selection logic for Integrated Messaging variant 1 see section 4 2 3 One to One Chat o Additional requirements for handling unseen messages and files see requirements for user story US5 13 Group Chat o Additional requirement introduced to allow the user to see who set up the Group Chat see requirement R6 6 2 IP Voice Call o Additional user story included to allow the user to see what the call bearer is in use for the call see requirements for user story US10 12 Introduction of LED notifications for received one to one group chat and file transfer messages Editorial clarifications to Audio Messaging and Messaging for Multi device sections Page 109 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document NOTE R9 5 10 NOTE V2 0 R9 5 11 R9 5 12
68. 13 2 As a developer want to be able to add RCS communication features to my application using RCS functionality exposed through APIs My app will be considered as an RCS enabled app US13 3 As a developer can provide stand alone applications which exploit RCS features accessed by APIs provided in the terminal or in the network US13 4 As a developer want to be able to integrate new RCS communication features into the native user interface using special APIs UI hooks at the following points e Messaging Application e Call Application s i e Dialler Call Set up Screen In call Screen Incoming Screen e Contacts Application e Call Logs e Sharing Touch point US13 5 As an Operator can identify which applications and its owner generates traffic through RCS APIs R13 5 1 App ID identifies the app which generates the traffic through the RCS APIs R13 5 2 Developer ID identifies the owner of the app R13 5 3 App ID and Developer ID are both unique V2 0 Page 137 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document R13 5 3 1RCS enabled app installed on a device offers one or more services that are identified by a specific ID a Feature Tag that is considered as a capacity of the user device US13 6 As a developer have to insert my App ID my Developer ID and the Feature Tags to be used in my source code allowing me to use RCS APIs US13 7 As a d
69. 2 0 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document Integrated Messaging 1 IM_CAP_ALWAYS_ON 0 Selected Messaging Service Connected Sender to cellular network Connected to RCS User B Connected Receiver to cellular network Connected to RCS Selected Service Default Change after capability confirmation Possible User Choice on device caching of unsent messages is required and user shall be informed Table 12 Table to explain and summarise static conditions and proposed Messaging Service by the device logic R4 13 2 Undelivered chat messages sent but not delivered R4 13 2 1When A Party is RCS online and a DELIVERY TIMEOUT expires sent but not yet delivered chat messages shall be considered as undelivered The user shall be able to send manually by SMS any undelivered chat messages by xMS R4 13 2 2The user shall be notified about undelivered chat messages e Inside the message thread through an indication in the thread message status indication The first time this indication is shown a contextual indication e g tool tip shall explain to the user what it means and what options the iser has e g resending via SMS V2 0 Page 47 of 166 GSM Association Official Document RCC 61 RCS Common Core 1 1 Service Description Document Non confidential This message is still Hi Zapp pending
70. 2 10 the codec profile selection shall follow the procedures described in section 3 6 4 1 4 and 3 6 4 1 5 of RCC 07 12 3 2 1 2 Upgrade to IP Video Call R12 24 11 The realisation for requirements of user stories US12 11 US12 12 US12 13 and US12 15 are covered in section 12 3 upgrade to IP video call bullet NOTE The parameter RCS IP VIDEO CALL UPGRADE FROM CS mentioned in R12 24 3 shall be taken into account regarding the availability to add video R12 24 12 Requirement R12 11 2 shall be implemented locally in the device R12 24 13 Requirements for user story US12 12 R12 12 1 and R12 12 2 are fulfilled via the required capability exchange as highlighted in section 12 3 R12 24 14 Requirements R12 12 3 and R12 12 4 shall be implemented locally in the device and consequently make the relevant capabilities available or not during discovery R12 24 15 Requirements R12 13 3 and US12 14 shall be implemented locally in the device V2 0 Page 134 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document 12 3 2 2 Image Share R12 24 16 The realisation for requirements of user story US12 16 R12 16 1 and R12 16 2 and US12 18 R12 18 1 R12 18 2 and R12 18 4 is covered in section 12 3 image share bullet R12 24 17 For the requirements of user story US12 17 it is recommended to follow the proposal for a compression mechanism summarised below In order to prov
71. 3 5 R2 3 6 R2 3 7 R2 3 8 There shall be only one active RCS client at any given point time to run ona device In case there is more than one RCS client on a device i e native RCS and one or more downloadable RCS clients the toggle RCS client switch shall provide the option to choose the RCS client that will be active The toggle RCS client switch shall not be visible as long as the RCS client is active If the user would like to activate another RCS client e g after downloading a new RCS client or by clicking on the toggle RCS switch of another currently inactive RCS client a popup or other relevant user notification providing a link to the toggle RCS client switch of the currently active RCS client shall be displayed If the user turns the toggle RCS client switch of the currently active RCS client off the respective RCS client shall be deactivated keeping all its entry points visible but e g greyed out disabled and all of its RCS user related content available e g Chat history files etc In this state the current deactivated RCS client is disconnected consequently no messages can be sent nor capability requests be answered Therefore the new client is automatically activated and connected to the RCS service The user shall be able to switch on the deactivated RCS client at any point in time e g by enabling its toggle RCS client switch triggering the deactivation process of the currently active client
72. 4 7 For the requirements in user story US14 2 the following applies R14 4 7 1The enhanced security function can be enabled or disabled by the service provider as defined in section 2 2 5 and 2 3 5 of RCC 07 R14 4 7 2The enhanced security function makes use of general client procedures for the user identification and authorization These procedures have only limited capabilities to convey operator specific explanatory text Only the out of band transaction provides the service provider with the capability to covey specific information However this is outside of the scope of this specification R14 4 8 For the requirements in user story US14 3 the following applies R14 4 8 1The RCS implementation assumes one common user identity managed 15 Data Off across all involved technologies e g SIM Device Configuration IMS Messaging Server Common Message store Voice and Video services It is the service provider responsibility to maintain this user identity and the related authentication permission and preference data in sync across all technologies and network services The RCS client shall use for RCS access only the user data retrieved from the SIM or via the user profile received from Device Configuration This allows the network to assign all traffic and service usage events to this single user identity 15 1 User Stories and Feature Requirements US15 1 As a user want to use operator voice and video calling irrespective
73. 58 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document R16 11 1 3Never resize R16 11 2 The default setting shall be always ask R16 11 3The resizing options shall be based on OEM developer choices including the default value of 480p 1200kbps R16 11 4When the set of resizing options are presented to the user the default one highlighted or selected shall be 480p encoded at a rate of 1200 kpbs R16 11 5 The video resizing shall be accomplished in the background and the user shall be able to take control of the phone instantly to e g but not limited to answer incoming calls make a call etc US16 12 As a user want to enable or disable the LED notification if such function is supported by my device R16 12 1 The user shall have the option to enable or disable the device LED for incoming message or File Transfer notification R16 12 2 The default setting shall be enabled US16 13 As a user want to enable or disable vibration notification for new incoming RCS messages or File Transfers R16 13 1 The user shall have the option to enable or disable the device vibration for incoming message or File Transfer notification R16 13 2 The default setting shall be enabled US16 14 As a software developer want to display on request an about page that explains details of the RCS client R16 14 1 The device shall provide the user with
74. 8 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document R4 5 1 Any application allowed to manage read write view xMS on a device shall also be allowed to manage read write view RCS chat messages R4 5 2 Any application selected by the user as the default messaging application shall manage xMS and RCS messages incl File Transfer as defined by the Operator Messaging rules R4 5 3 Notifications for new incoming RCS or xMS messages shall be handled according to the specifications in 1 to 1 Chat page 61 Group Chat page 71 and File Transfer incl Geolocation Push page 84 and shall not be replicated across multiple apps on a device NOTE This shall be to avoid a situation where a read message is still seen as unread in another application R4 5 4 Notifications for new incoming RCS or xMS messages in case the user has multiple RCS devices shall be handled in line with the requirements of Messaging for Multi Device page 102 NOTE This shall be to avoid a situation where a read message is still seen as unread from another device when connected R4 5 5 Any application managing xMS and RCS chat messages on a device shall follow the rules prescribed in this Operator Messaging section R4 5 6 The Operator Messaging conversations shall be visible from the native messaging icon and or the icon of the application which has take
75. 9 1 6 of RCC 07 16 RCS Settings 16 1 Description RCS is a Service Platform for Operators to develop and implement new communication services To allow users to manage their RCS services appropriately a Settings function needs to be implemented into devices clients 16 2 User Stories and Feature Requirements US16 1 As a user want to switch between RCS instances on one device to ensure smooth operation NOTE Details of the behaviour of this switch are described in Differences to V2 0 previous versions Page 155 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document RCS Common Core 1 1 is a maintenance update that provides further clarification to existing requirements The technical information has also been updated to align with RCS 5 3 see section 1 5 of RCC 07 16 2 1 Summary of Changes e Device Provisioning o Alignment with RCC 14 and RCC 15 e Capability Discovery and Service Availability o Clarification on the behaviour of the CAPABILITY VALIDITY timer see requirement R3 3 7 5 6 e Operator Messaging o Clarification to the Integrated Messaging requirements for proposed message selection see section 4 2 1 1 o Clarification on the DELIVERY TIMEOUT behaviour and technology selection logic for Integrated Messaging variant 1 see section 4 2 3 e One to One Chat o Additional requirements for handling unseen messages and files see re
76. Document R9 5 20 R9 5 21 R9 5 22 R9 5 23 R9 5 24 R9 5 25 R9 5 26 R9 5 27 R9 5 28 NOTE V2 0 Requirement R9 3 10 shall be implemented locally on the device File Transfer and thumbnails procedures are covered in File Transfer incl Geolocation Push page 84 Requirement R9 3 11 is covered for registered and connected devices As described in section R9 5 4 as long as there is no explicitly chosen active device all devices will receive the incoming requests Requirement R9 3 12 fully covered in RCS when the messaging realization is based on OMA CPM see RCC 11 With a strict messaging realization based on OMA SIMPLE IM a network internal proprietary solution is required since OMA SIMPLE IM s multi device approach does not support the requirement for Group Chat Requirement R9 3 13 is mainly covered due to the synchronization with the Common Message Store as described in section R9 5 6 In addition a device can know if a request has been accepted on another device due to the reason header provided in the SIP CANCEL as described in section 2 11 1 of RCC 07 or SIP BYE as described in sections 3 4 1 7 1 and 3 4 4 1 8 1 of RCC 07 Requirement R9 3 14 is covered as described in section 3 3 4 1 7 of RCC 07 For requirement R9 3 16 the link between the app and the RCS stack is up to implementation Note that not all kinds of events can be delivered in real time due to the limitations explained in sec
77. Document RCC 61 RCS Common Core 1 1 Service Description Document V2 0 R9 3 4 5 Geolocations R9 3 4 6 vCards R9 3 4 7 Audio Messages R9 3 4 8 Files R9 3 5 R9 3 6 R9 3 7 R9 3 8 R9 3 9 R9 3 10 R9 3 11 R9 3 12 R9 3 13 All events belonging to services listed in R9 3 4 shall be made available to the user s other RCS enabled devices even when these services and events are being managed by another application on the device OM an RCS user with multiple RCS enabled devices shall have the messaging features and contents that are available to them on the primary device also available on their secondary devices and interfaces An RCS user with multiple RCS enabled devices shall have their conversation history for all events belonging to the services listed in R9 3 4 available on all of their RCS enabled devices and interfaces no matter which one was used to accept send or manage the content The message and content history shall be synchronised across all devices and interfaces as soon as possible Events messages content and notifications shall be synchronised with devices and interfaces so that for each conversation the most recent events are synchronised first Client implementations may choose to display and therefore synchronise only the most recent set of events messages contents associated with services listed in R9 3 4 on the devices and interfaces that were inactive for the conversation
78. E Directory Profile IETF RFC http tools ietf org html rfc2426 18 RFC5547 A Session Description Protocol SDP Offer Answer Mechanism to Enable File Transfer IETF RFC http tools ietf org html rfc5547 vCard The Electronic Business Card A versit Consortium Specification 18 Sep 1996 http www imc org pdi vcard 21 doc 19 vCard21 1 3 Conventions It is a shared understanding by the standardizing RCS operators that any service described in the RCS standard may or may not be offered by any given mobile network operator however it is agreed that if a feature is supported by an operator the Feature Requirements which are marked OM operator mandatory shall be supported NOTE For device manufacturers and client developers requirements are classified based on the conventions defined in section 1 4 of this document For the purpose of this document user stories are identified using the following numbering convention US N 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 R N N N where R requirement e g R2 2 1 Sub requirements will appear as a third level e g R 2 2 1 1 1 4 Requirement and Technical Realization Classification Term Description Shall These terms dictate that a functionality and or process is Mandatory Shall Shall Not These terms dictate that a functi
79. February 2015 http www gsma com GSMA PRD RCC 09 RCS 5 3 Endorsement of OMA CPM 2 0 Message Storage Version 5 0 28 February 2015 http www gsma com GSMA PRD RCC 10 Rich Communication Suite 5 3 Endorsement of OMA CPM 2 0 Interworking Version 4 0 http www gsma com GSMA PRD RCC 11 Rich Communication Suite 5 3 Endorsement of OMA CPM 2 0 Conversation Functions 10 RCC 11 Version 4 0 28 February 2015 http www gsma com GSMA PRD RCC 14 Service Provider Device Configuration Version 1 0 16 February 2015 http www gsma com GSMA PRD RCC 15 IMS Device Configuration and Supporting Services Version 1 0 16 February 2015 http www gsma com GSMA PRD RCC 53 joyn Device API Specification Version 2 0 16 October 2014 http www gsma com GSMA PRD RCC 55 TAPI Security RCS Extensibility Terminal API Security 14 RCC 55 Version 1 0 15 October 2014 http www gsma com Blackbird Product Definition Document 15 RCC 60 version 4 0 www gsma com A MIME Content Type for Directory Information IETF RFC http tools ietf org html ric2425 7 IRCC 07 8 RCC 09 9 RCC 10 11 RCC 14 12 RCC 15 13 RCC 53 16 RFC2425 V2 0 Page 6 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document Ref Doc Number _ Title 17 RFC2426 vCard MIM
80. GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document GSMA RCS Common Core 1 1 Service Description Document Version 2 0 04 March 2015 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 2015 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 0 Page 1 of 166 GSM Association Official Docume
81. GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document RCS disabled permanently RCS not visible in the device RCS on set up process RCS not visible in the device HTTP request active HTTP request on hold RCS runs for the first time or RCS service activation triggered by the network Is it a RCS network User clicks Yes set up button 5 Network accepts user s service activation Yes MNO requires T amp C acceptance RCS active RCS visible and active Does user accept T amp C s RCS instance switch not visible User activates another RCS instance on same device Other RCS instance B RCS in pre launcher mode 75 RCS in launcher mode RCS instance not active but requesting RCS instance not active nor visible in the device with the exception of RCS set up icon HTTP request on hold user to switch off currently running RCS instance HTTP request on hold User switches currently active RCS instance A OFF e g via link in instance B that guides him to according setting of RCS instance A V2 0 Page 15 of 166 GSM Association Official Document RCC 61 RCS Common Core 1 1 Service Description Document Non confidential User switches currently active RCS instance A OFF e g via link in instance B that guides him to according setting of RCS instance A Former active RCS instance A N
82. It will be delivered when the How are you contact is back online again R Cinema SMS a Figure 10 Example of a tool tip indication to notify the user of undelivered chat messages R4 13 3 In the messaging inbox R4 13 3 1The user shall be informed through a system notification that R4 13 3 1 1 Some messages have not yet been delivered R4 13 3 1 2 Those messages will be delivered when the receiver is back online R4 13 3 1 3The user shall be able to resend one or all of the undelivered messages by SMS R4 13 3 2Opening the notification shall forward the user to the associated message thread R4 13 3 3The same indication should be displayed in both the inbox view and the associated message thread view Ce Message I pa O Zapp o 02115335969 m Mikyoung upaa Figure 11 Example of indication in Inbox of a thread containing undelivered messages R4 13 4 When outside the message thread or inbox the user shall be informed through a system notification that R4 13 4 1 Some messages have not yet been delivered R4 13 4 1 1 These messages will be delivered when the receiver is back online again R4 13 4 1 2 The user is able to resend these messages by xMS V2 0 Page 48 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document R4 13 4 2 Opening the notification shall forward the user to the associated message thread 4 2 3 5 Unsent Chat Messages
83. M Any content deleted or removed from a device or interface that was not explicitly deleted by a user action or consent shall not be deleted from the Common Message Store nor any other device or interface NOTE SIM swap shall not delete locally stored content on the device Factory reset shall not cause deletion on the Common Message Store R9 3 25 An RCS user with multiple RCS enabled devices and interfaces shall be able to log out of an identity on a secondary device or interface and another user will be able to log into that device or interface with a different identity R9 3 26 OM An RCS user with multiple RCS enabled devices or interfaces shall be able to start a messaging conversation Chat and or xMS from one of their devices interfaces and continue it from any of their other devices interfaces R9 3 27 OM The user shall continue the conversation on another device or interface by opening the messaging thread associated with the conversation they would like to pursue on that device interface As soon as they respond to a message or piece of content on this newly used device interface it becomes the active device interface for that messaging session and messages content are no longer delivered automatically to the previously active device interface US9 4 As an RCS user can have multiple conversations active at the same time using different devices and or interfaces e g am chatting to Alice using my mobile whilst at
84. MSI is available a device shall not ask the user for the MSISDN and shall instead attempt the configuration providing only the IMSI in the HTTP request 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 of and its subsections providing the procedure required in requirements R2 1 1 R2 1 2 R2 1 2 1 R2 1 2 2 R2 1 3 and R2 9 1 with the error handling described in section 2 3 3 4 covering the behaviour required in R2 1 4 and R2 1 5 The device shall assume that RCS is available on the user s network if DNS resolution of the HTTP configuration URL is possible using the MCC and MNC obtained from the SIM card As described in US2 11 if the IMSI is available a device shall not ask the user for the MSISDN and shall instead attempt the configuration providing only the IMSI The operator limitation required in R2 9 2 is covered by the Note in section 2 3 2 of Configuration of additional devices shall be done as described in section 2 5 of realising the requirements in section US2 8 The rcs_profile parameter shall be included in the HTTP GET requests and set to CommonCore_ 1 0 To ensure that there is only one client active on a particular device as required in R2 3 1 to R2 3 8 a device local solution is required which will therefore be Page 20 of 166 GSM Association Non confidential Official Document RCC 61 RC
85. Messaging requirements for proposed message selection see section 4 2 1 1 o Clarification on the DELIVERY TIMEOUT behaviour and technology selection logic for Integrated Messaging variant 1 see section 4 2 3 e One to One Chat o Additional requirements for handling unseen messages and files see requirements for user story US5 13 e Group Chat o Additional requirement introduced to allow the user to see who set up the Group Chat see requirement R6 6 2 e IP Voice Call o Additional user story included to allow the user to see what the call bearer is in use for the call see requirements for user story US10 12 e Introduction of LED notifications for received one to one group chat and file transfer messages e Editorial clarifications to Audio Messaging and Messaging for Multi device sections NOTE Further improvements to the Messaging for Multi device section Such as introduction of synchronisation triggers are expected once the work of the Multi device Messaging Operator Interest Group has been concluded R16 16 2 Device Provisioning page 10 R16 16 3The requirements for user story US16 2 shall be implemented locally on the device The value of the parameter is used by the client to populate the User Alias as defined in 2 5 3 3 of RCC 07 R16 16 4The requirements for user story US16 3 shall be implemented locally on the device The client configuration is only relevant if the service provider has activated the IP Voice Call on
86. N OFF OM If an RCS user A Party is in an active session with another RCS user B Party with multiple RCS enabled devices and the B Party is using a mobile i e primary device to chat it is possible that the B Party loses their data connectivity In this case the conversation shall persist between user A and user B on the B Party s mobile device following the rules of Integrated Messaging e g relying on Store and Forward or falling back to SMS until the session ends Page 105 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document R9 3 21 An RCS user who has chosen to leave a Group Chat on one of their connected devices or interfaces shall stop receiving any further updates from that Group Chat on their other devices and interfaces R9 3 22 OM Any events messages content and notifications associated with services listed in R9 3 4 that are deleted by a user on any of his RCS enabled devices or interfaces shall also be deleted from the Common Message Store and their other RCS enabled devices and interfaces R9 3 22 1When deleting an event the user may be warned that it will also be deleted from thier other devices and interfaces A don t ask again prompt may be offered R9 3 23 OM Any content that has been deleted from the Common Message Store by the system e g content expiry shall not be deleted from any of the user s devices or interfaces R9 3 24 O
87. Occurrence Format Min Access Types Required ZeroOrOne Bool Get Replace Table 9 UX MO sub tree addition parameters incallUX e Values 0 the In call service entry point will be conditionally visible and conditionally selectable 1 the In call service entry point will be conditionally visible and always selectable Post reconfiguration actions As the client remains unregistered during configuration there are no additional actions apart from de registering using the old configuration and registering back using the new parameter e Type property of the node is urn gsma mo gcc ux 1 O incallUX e Associated HTTP XML characteristic type incallUX Node lt x gt Ext An extension node for service provider specific parameters Clients that are not aware of any extensions in this subtree e g because they are not service provider specific should not instantiate this tree Status Occurrence Format Min Access Types Optional ZeroOrOne Node Get Table 10 UX MO sub tree addition Service Provider Extension Node V2 0 Page 34 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document V2 0 Values N A Type property of the node is urn gsma mo gcc ux 1 0 Ext Post reconfiguration actions The client should be reset and should perform the complete first time registration procedure following a reconfiguration e g OMA DM HTTP Associated HTT
88. P XML characteristic type Ext R3 4 5 R3 4 6 R3 4 7 R3 4 8 R3 4 9 R3 4 10 R3 4 11 R3 4 12 R3 4 13 R3 4 14 R3 4 15 R3 4 16 R3 4 17 Requirement R3 3 4 requirement is implemented locally on the device Requirements under R3 3 5 are implemented locally on the device and shall follow limits described in is supported when any RCS service tag is exposed discovered Requirements under R3 3 6 shall follow 2 6 2 RCC 07 The client configuration parameter DISABLE INITIAL ADDRESS BOOK SCAN shall either not be provisioned or be set to 0 R3 3 7 1 requirement shall use POLLING PERIOD in A 1 11 RCC 07 R3 3 7 2 requirement shall use CAPABILITY INFO EXPIRY in A 1 11 RCC 07 Requirements R3 3 7 3 and R3 3 7 4 requirements are implemented locally on the device R3 3 7 5 requirements shall follow 2 6 2 1 2 6 3 1 3 3 6 3 and 3 3 4 1 3 RCC 07 R3 3 7 5 5 requirement parameter is defined in Operator Messaging page 36 Requirement R3 3 7 5 6 is implemented locally on the device Requirement R3 3 7 5 7 and R8 3 7 5 8 are implemented locally on the device Requirement R3 3 7 5 7 and R3 3 7 5 8 follows 2 6 3 1 RCC 07 after a voice call is established Requirements under R3 3 7 6 shall follow TE1 or TE2 capability discovery optimizations defined in 2 6 3 2 6 4 and A 1 11 RCC 07 Requirement R3 3 7 7 3 shall follow 2 6 4 1 RCC 07 Requirement R3 3 7 7 5 applies only to TE1 Requirement 3 3 7 8
89. R15 5 11 Requirement R15 2 2 shall be implemented locally on the device Since the device has no defined way to find out automatically compliancy to the airline policy for enabling Wi Fi is up to the end user R15 5 12 Requirement R15 2 3 shall be implemented locally on the device taking into account the behaviour of RCS services in relation to the current data off setting configured as per R15 5 21 R15 5 13 Requirement R15 2 4 is fulfilled for SMS over CS When using SMS over SGs Signalling Gateways in LTE coverage the device shall establish a data connection even when data is turned off in which case the device shall not allow any data over that connection unless allowed as per R15 5 21 SMS over IP shall only be possible when Data is switched on or when SMS over IP is allowed when Data is off as per R15 5 21 Page 154 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document R15 5 14 For requirement R15 2 5 the HPLMN operator can apply any tariff scheme for any operator messaging service For the VPLMN operator tariffs the restrictions in R15 5 10 should be taken into account R15 5 15 For requirement R15 2 6 MMS shall be available when data is off if allowed as per R15 5 21 This shall be implemented locally on the device R15 5 16 Requirement R15 2 7 shall be implemented locally on the device R15 5 17 Requirement R15 2 8 shall be implemented locally on the device
90. RCS offline or A Party has not yet determined B Party s availability or B Party is not an RCS user then MMS shall be the proposed File Transfer service NOTE This shall be the case even if B Party is a known RCS user R4 15 3 5lf after the A Party user has entered the file selection process B Party s capabilities for RCS File Transfer are received the proposed File Transfer Service shall be adjusted to RCS File Transfer if the change is visible to the user can be manually changed back and if the user has not manually selected the Messaging Service in this Session before NOTE Taking into consideration the exception detailed in R4 15 3 3 V2 0 Page 51 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document R4 15 4 lf A Party is registered to RCS online but outside of cellular coverage the current capabilities of B party shall determine the proposed File Transfer Service NOTE A capability check for B Party shall be performed in the background whenever A Party enters the messaging composer and selects a recipient B Party or if A enters into a conversation with B or when A Party enters any of the relevant File Share service entry points and selects a recipient B Party R4 15 4 1 lf B Party is registered to RCS online then RCS File Transfer service shall be proposed R4 15 4 2lf B Party is not registered to RCS offline or A Part
91. RI tag set in the Contact header as described in section 2 4 4 5 of RCC 07 R13 18 18 Requirements for user story US13 15 is covered through procedures of section 4 4 2 of RCC 53 R13 18 19 Requirements for user story US13 16 are applicable to all application using API i e either derived from user story US13 7 or US13 8 They can be ensured at the network level and are up to service provider policy Identification of the app generating a specific traffic may be done by linking the data plane with the SIP session that has allowed the data session establishment as the SIP INVITE request that was used to set the session shall convey the identity of the app through its IARI tag set in the Contact header as described in section 3 12 4 1 and 3 12 4 2 of RCC 07 NOTE An application derived from requirement US13 8 cannot be identified when using standalone messaging using SIP Message R13 18 20 Requirements for user story US13 17 are covered for MNOs applications through the security model defined in RCC 55 For Third Parties applications this requirement is not covered yet R13 18 21 The requirements of user story US13 18 are covered e At the UNI level a Service Provider can control dynamically the authorization of any app to access the RCS infrastructure for any user via the EUCR mechanism described in section 3 12 4 3 of RCC 07 These network initiated requests indicate to the device to block an app or a list of apps for a certain
92. S Common Core 1 1 Service Description Document OS specific For the Android OS this shall be implemented locally on the device as follows e Identifying Android applications as RCS clients using a Manifest xml meta data property e Identifying if a RCS client is enabled by accessing its Shared Preferences and reading a property from it e Accessing a RCS client settings screen by sending an intent using the action defined as a Manifest xml meta data property NOTE This recommendation applies to all clients embedded or downloaded and that any value add service propositions which involve complementing the RCS proposition with additional services or RCS services using alternative platforms are not required to follow the procedures described in this section e In order to prevent having two RCS clients on the same device and therefore negative consequences in the user experience the following mechanism shall be implemented by both RCS embedded and OTT client implementations This mechanism is based on the following principles R2 11 6 Client requirements R2 11 6 1Android RCS clients shall define the following meta data properties in their Manifest xmI file e Name WEEE e Description gsma joyn client true Used to identify the application as an RCS client gsma joyn settings a lt String gt Equals to the intent action that be used to ctivity start the RCS client settings screen Table 2 Android RCS cl
93. S5 14 As a user want the contact names of Chat Conversations to be aligned with the according contact card i e if a Contact am in a Chat Conversation with is in my contact list the identifying MSISDN shall be replaced with the name from the contact card R5 14 1 OM If the sender of a Chat Message is in my contact list the MSISDN shall be replaced with the sender s name on the contact list in any representations where the message sender is represented R5 14 2 OM If the sender of a Chat Message is not in my contact list the MSISDN shall be replaced with the sender s RCS Alias name if available R5 14 3 OM Incase the Alias is being used to represent the sender s identity the device UI shall use appropriate means to make transparent that the Alias name is unverified information NOTE The Alias as specified in RCS 5 2 standard is being created by the message sender and could be set to any possible name the real name of the person or a nickname or in extreme cases in an attempt of identity spoofing the sender could try to pretend a false identity V2 0 Page 65 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document US5 15 As auser don t want to feel restricted by Chat Message size limits R5 15 1 OM Chat Messages incoming and outgoing shall allow to enter at least 999 characters NOTE Operator defined parameter US5 16 As a user want to exchange mu
94. SDD introduces two video services Video over LTE ViLTE IR 94 and RCS IP Video Call ViIP both captured under the term IP Video Call From a user s perspective all three services shall be available as Live Video Selection of the technical enabler is dependent on available network conditions in the end to end usage scenario Each technology has its benefits and limitations and the individual use is based on each operator s configuration US12 2 As a network operator want to configure which video call technology shall be used when pressing the single share live video button in case both capabilities of Video Share and IP Video Call are available R12 2 1 There shall be only one button displayed to the user to enable share live video during an ongoing voice call irrespective of the actual voice call bearer R12 2 2 The network operator shall be able to configure which Live Video technology shall be used in case both capabilities for Video Share and IP Video Call are available R12 2 3 In general in case both capabilities for Video Share and ViLTE are available ViLTE shall prevail R12 2 4 Whenever neither ViLTE nor ViIP depending on selected profile is supported the Live Video functionality shall be delivered as Video Share if available end to end Based on the available technology options to deliver the Live Video functionality various combinations are possibl
95. a progress bar that indicates the transfer of the file from network store to receiving device after download was triggered R7 13 6 3Cancelled the receiver shall have the option to cancel the File Transfer during the File Transfer process R7 13 6 4 File downloaded R7 13 6 5File Transfer failed File Transfer could not be confirmed successfully completed by the network and client does not attempt to retrieve the file any further In case of File Transfer store amp forward function is available the user may be able to manually re trigger File Transfer and resume from where the File Transfer failed In case of no File Transfer store amp forward the user has the option to ask the sender to re send the file US7 14 As a user want to transfer a Contact s information from the contact list to other RCS users R7 14 1 Selecting Send Contact from a Contact Card shall send the Contact details in vcf format to a recipient that shall be selected NOTE vCard as the default format details in the Annex A1 Personal Card format page 162 R7 14 2 OM Devices shall be capable to render vCard files in vcf format according to RCS standard see Annex A1 Personal Card format page 162 and offer to store received Contacts in the device contact list US7 15 As a user want to be able to resume interrupted File Transfers NOTE On sending and receiving side R7 15 1 f a File Transfer has been interrupted on the sendi
96. ages shall be queued locally on the device and will be sent once the connection to cellular is restored NOTE device In case cellular is not available the SMS shall be locally queued on the Integrated Messaging 2 IM CAP ALWAYS ON 1 Selected Messaging Service User A Connected Sender to Cellular Network Connected to RCS User B Connected to Cellular Receiver Network N A Connected to RCS Selected Default RCS SMS RCS SMS Service User Choice SMS RCS SMS N A On device caching of messages is required and user shall be informed If B Party is known to be a non RCS user If cellular network connection is not available on device caching of messages is required and user shall be informed Table 13 Table to explain and summarize static conditions and proposed Messaging Service by the device logic 2 Cellular data is switched on 3 Cellular data is switched off V2 0 Page 50 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document 4 2 5 Integrated Messaging File Transfer 1 FT_HTTP_CAP_ALWAYS_ ON 0 online Experience only US4 15 As a user want the best File Transfer service to be proposed to me to convey my files R4 15 1 The File Transfer Service to be proposed for sending files shall be determined by the registration status to RCS platform of the sender A Party and receiver
97. al Information 140 13 3 1 Overview 140 13 3 2 Requirements matching 141 14 Security against Malware 144 14 1 Description 144 14 2 User Stories and Feature Requirements 144 14 3 Technical Information 145 14 3 1 User Authentication 145 14 3 2 Encryption 146 14 3 3 Storage of Authentication and Identification Data 146 15 Data Off 149 15 1 User Stories and Feature Requirements 149 15 2 Technical Information 153 16 RCS Settings 155 16 1 Description 155 16 2 User Stories and Feature Requirements 155 16 3 Technical Information 160 Annex A Supporting requirements 162 A 1 Personal Card format 162 A 2 Emoticon conversion table 164 A 3 Unicode Standard Emoji Emoticons 166 Annex B Document Management 166 B 1 Document History 166 B 2 Other Information 166 V2 0 Page 4 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document 1 Introduction 1 1 Purpose of the document The RCS Common Core Service Description Document provides guidance to Original Equipment Manufacturers OEMs for open market device implementations and guidance to Application Developers for downloadable client implementations The document provides user stories feature requirements and technical information based on the RCS specification and a prioritised set of features which Mobile Network Operators MNOs can launch 1 1 1 Structure of the document The document details how the features are to be implemen
98. all have the option to restore Group Chat Conversations from the Common Message Store e g in case of handset replacement US6 36 As a user want to block specific users so that do not receive any kind of Group Chat Message from them anymore However want to be aware that there was a message of a blocked contact to understand the context of the Group Chat want to see that even blocked contacts are participating in a Group Chat Conversation R6 36 1 OM lf one or more participants in a Group Chat Conversation are on my local device blacklist these contacts shall appear on the list of Group Chat participants R6 36 2 lf the sender of a Group Chat Message is on my local device blacklist the incoming message shall be shown as an anonymous empty placeholder message in the message thread No visual or audio notification shall be performed for that message V2 0 Page 80 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document 6 3 Technical Information 6 3 1 Overview The group chat service is provided as defined in section 3 4 of RCC 07 For the purpose of the following technical implementation of the user stories and service requirements the group chat service is considered as a stand alone end to end service RCC 07 allows service providers to implement the group chat user experience based on SIMPLE IM or CPM The service provider is able to select the technology via
99. ameras the front facing camera shall be activated by default when the video transmission is started US11 14 As users in an IP video call we i e user A B want to see an indication of the connection quality on the in call screen so that we know that compromises on the video quality might be due to limitations in the local data connectivity leg R11 14 1 During an ongoing IP Video Call a connection quality indicator should be displayed on the in call screen to indicate risk of video call switching to audio only or dropping completely due to unsatisfactory coverage US11 15 As users in an IP video call we i e user A B want to upgrade a two way IP video call to a multiparty video call As users in an IP video call when a party leaves a multiparty video call the IP video call continues between the remaining IP video call parties R11 15 1 An IP video call shall be delivered minimum as a 1 to 1 video call but may be distributed on the network to support a multiparty video call US11 16 As a service provider may want to allow supplementary services during IP video calls when another voice video call comes in such as Calling Line Identification Presentation CLIP Call Waiting CW Call Hold Call Forward Busy CFB Call Forward Unreachable and Call Forward No Reply R11 16 1 Supplementary Services such as Calling Line Identification Presentation CLIP Call Waiting CW Call Hold Call Forward Busy CFB Call Forward
100. an about page that indicated the version of the device and the RCS implementation to allow efficient identification of the client device details US16 15 FOR INTEGRATED MESSAGING As a user want to be able to change my preference for whether undelivered RCS messages are automatically sent again by SMS or not R16 15 1 The user shall be able to set one of the following options R16 15 1 1 Always resend undelivered RCS messages as SMS R16 15 1 2 Always ask R16 15 1 3 Never resend undelivered RCS messages as SMS R16 15 2 The default setting shall be always ask V2 0 Page 159 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document 16 3 Technical Information US16 16 Anumber of requirements for service configuration parameters on the client are provided The technical implementation of the requirements for user story US16 1 are provided in Differences to previous versions RCS Common Core 1 1 is a maintenance update that provides further clarification to existing requirements The technical information has also been updated to align with RCS 5 3 see section 1 5 of RCC 07 16 3 1 Summary of Changes e Device Provisioning o Alignment with RCC 14 and RCC 15 e Capability Discovery and Service Availability o Clarification on the behaviour of the CAPABILITY VALIDITY timer see requirement R3 3 7 5 6 e Operator Messaging o Clarification to the Integrated
101. and possibly unread message identifier in the list of Chat Conversations US6 18 As a user want conversations which contain unread messages to be differentiated from conversations that contain messages have seen NOTE This requirement shall be valid for Messaging for Multi Device as well R6 18 1 Group Chat Conversations shall on reception of a new message elevate to the top of the Conversation list R6 18 2 Group Chat Conversations with unread messages shall be marked accordingly e g by display of subject line in bold font and or an unread message counter US6 19 As a user I want to receive text Group Chat Messages from any of the contacts participating in a Group Chat Conversation R6 19 1 OM Any RCS user shall be able to receive Chat Message s that are sent to Group Chat Conversations the user participates in at any point in time NOTE Group Chat Participants who are blacklisted on the user s device are treated separately R6 19 2 OM Group Chat Messages shall be received straight in the inbox no hand shake acceptance shall be required R6 19 3 OM Any participant of a Group Chat shall only be able to see messages that have been exchanged between the time of joining the Group Chat and leaving the Group Chat NOTE Group Chat Participants who are blacklisted on the user s device are treated separately R6 19 4 OM It shall not be possible for any participant of a Group Chat Conversation to see any messages that
102. ased on SIMPLE IM or CPM The service provider is able to select the technology via the CHAT MESSAGING TECHNOLOGY configuration parameter defined in section A 1 4 3 of RCC 07 5 3 2 Technical Implementation of User Stories and Service requirements R5 26 1 For user story US5 1 the following definitions apply e The 1 to 1 Chat service shall be offered to the user if the device configuration authorizes the chat service via the CHAT AUTH parameter defined in section A 1 4 3 of RCC 07 e The ability of the user to send chat messages to a contact depends on the result of the capability discovery and the service provider s capability to support store and forward as defined in section 2 7 of RCC 07 e As defined by requirement R5 1 2 the chat transfer technology requires the client to create and manage a chat session without making it visible to the user The chat session shall be managed by the client with regard to the session acceptance and time out as defined by the configuration parameters IM SESSION START IM SESSION AUTO ACCEPT and IM SESSION TIMER of RCC 07 V2 0 Page 68 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document R5 26 2 NOTE V2 0 R5 26 3 R5 26 4 R5 26 5 R5 26 6 R5 26 7 R5 26 8 R5 26 9 For the message transfer states of requirement R5 2 1 the following technical implementation applies e Pending When the user presses ENTER
103. associated message thread 4 2 4 Integrated Messaging 2 IM_CAP_ALWAYS_ON 1 RCS Chat as default between RCS users US4 14 As a user want the best Messaging Service to be proposed to me to convey my messages R4 14 1 The messaging service to be proposed for sending messages to RCS capable users shall be determined by the connectivity status to the RCS platform of the sender A Party R4 14 1 1RCS Chat shall be the default Messaging Service for outbound messages proposed by the device for recipients B Party being known as RCS capable contacts irrespective of their connectivity status R4 14 2 lf the A Party has lost IP connectivity to the RCS service messages to B Party being an RCS user shall be 1 to 1 Chat locally queued and sent once the IP V2 0 Page 49 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document connectivity is restored In this case the A Party shall be informed about the loss of the connectivity status by the device appropriately R4 14 2 1lf the A Party is not registered to the RCS service e g the user has chosen to switch their mobile data setting to OFF the proposed Messaging Service shall be SMS R4 14 3 SMS shall be the default messaging service for outbound messages proposed by the device logic for recipients B Party being known or detected as not RCS capable In case the device has no cellular connectivity SMS mess
104. at then the CAB PCC MIME type application vnd oma cab pcc xm shall be used On the receiving side after the receiving RCS user accepts the contact card file delivered through File Transfer the receiving RCS client shall apply the mapping of the RCS supported fields between the received format CAB PCC XML for example and the used format of the local address book database vCard 3 0 format is recommended in RCS If the receiving side does not support the offered format identified in the a file selector attribute of the SIP INVITE SDP it should reject the File Transfer invitation with an error response indicating it does not support the content type which then causes the sending side to initiate a second File Transfer this time sending the contact card in a different format 4 If the conversion between PCC and vCard is required please see CAB_TS section 5 4 3 Format Adaptation Page 163 of 166 GSM Association Non confidential RCS Common Core 1 1 Service Description Document A 2 Emoticon conversion table Standard Emoticons Exampl ribing graphical Emoticons Character sequences kampies describing graph renditions Happy smile or A happy or smiling face Sad or A sad face Wink or or 0 or O A winking face D or D or oD or d or d or od or Od or OD Confused or A confused face Big grin A big grin face Blushing embarrassed and or or gt or or
105. ate R6 37 11 The implementation of the smilies and emoji in the requirements of US6 10 shall be supported as defined in the documents in the Annex R6 37 12 For the realization of the requirements in user story US6 11 the client shall enforce the max message size for sending messages as defined by the configuration parameter MAX SIZE GROUP IM defined in section A 1 4 3 of RCC 07 It is required for service providers to set the value to 999 or more R6 37 13The Status indication for chat messages and File Transfer sent in the group chat are the same as defined for 1 to 1 Chat in 1 to 1 Chat page 61 and File Transfer in File Transfer incl Geolocation Push page 84 R6 37 14 Notifications on delivery status information as defined in R6 12 2 shall be stored and forwarded in the store amp forward server as specified in section 3 4 4 3 of RCC 07 R6 37 15The requirements for US6 13 to display typing notifications is implemented same as for 1 to 1 Chat as defined in section 3 4 4 of RCC 07 Page 82 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document R6 37 16 The requirements for user stories US6 14 through to US6 16 are implemented locally on the device R6 37 17The subject of a Group Chat Conversation as required in requirement R6 17 1 is implemented as defined in user story US6 2 There is no technical implementation of a group chat icon R6 37 18 Th
106. ated Messaging File Transfer 1 FT_HTTP_CAP_ALWAYS_ON 0 online Experience only 4 2 6 Integrated Messaging File Transfer 2 FT_HTTP_CAP_ALWAYS_ON 1 File Transfer with Store and Forward 4 2 7 Multimedia Message Service Selection 4 3 Technical Information Non confidential NN OOO O 11 11 12 12 13 16 18 19 20 20 20 25 25 25 30 30 36 36 36 40 42 43 49 51 52 53 54 Page 2 of 166 GSM Association Official Document RCC 61 RCS Common Core 1 1 Service Description Document 10 11 V2 0 4 3 1 Overview 4 3 2 Configuration Parameters 4 3 3 Capability Discovery 4 4 Technical Implementation of User Stories amp Feature requirements 1 to 1 Chat 5 1 Description 5 2 User Stories and Feature Requirements 5 3 Technical Information 5 3 1 Overview 5 3 2 Technical Implementation of User Stories and Service requirements 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 File Transfer incl Geolocation Push 7 1 Description 7 2 User Stories and Feature Requirements 7 3 Technical Information 7 3 1 Overview 7 3 2 Technical Implementation of User Stories and Service requirements Audio Messaging 8 1 Description 8 2 User Stories and Feature Requirements 8 2 1 Sending Audio Messages 8 2 2 Notification on Receiving Audio Messages 8 2 3 Rec
107. ation data user identification data password token used for network access The client shall store this data in a secure manner to prevent access from users and invaders For the requirements in user story US14 1 the following applies V2 0 R14 4 5 RCS makes use of a number of authentication mechanisms with some of them being vulnerable to attacks as summarized on a high level in section 14 3 1 Thus the risk that 3 party applications are able to retrieve user data or to make Page 146 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document use of communication services on behalf of the user persists The main RCS vulnerability comes from the fact that user identification and authentication data is made available to consumers via a device management technology with weak security measures The following authentication mechanisms and encryption methods are used on a UNI technology basis R14 4 5 1HTTP s based client configuration in 3GPP access makes use of either the Generic Bootstrapping Architecture GBA 1 or network based user identification via 3 as defined in section 2 4 and 2 2 of respectively As defined in section 2 2 5 the service provider may decide to further secure the identification via invocation of the SMS based procedure which adds additional authentication via 4 The SMS based procedure may be further secured by the service provider by enf
108. ay video in 352x288 pixel resolution 15 fps or better the A Party shall be able to trigger a 1 way IP Video Call to B Party device B Party obviously shall have no option to activate the video channel back to A Party R12 12 4 n case the B Party device does not have a camera built in neither front facing nor rear facing and is not able to display video in 352x288 pixel resolution 15 fps or better the A Party shall not be able to trigger an IP Video Call to B Party US12 13 As a user during a voice call all bearers receiving an incoming IP video call from the other participant of the ongoing call i e user B want to decide whether to g Decline the video call and continue with a plain voice call h Accept the video call without transmitting my camera view or i Accept the video call with transmitting my camera view R12 13 1OM The receiver shall be able to accept or decline an incoming IP video call R12 13 2OM Upon decline by the receiver the voice call shall continue seamlessly V2 0 Page 128 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document R12 13 3OM For acceptance the receiver shall have the option to answer the incoming IP video call with or without transmitting the own camera view back to the sender NOTE It is acceptable though that during signalling set up of the IP Video Call the CS call is muted but it is not dropped If the in
109. be able to forward a single sent or received chat message or multimedia content to one or more Contacts NOTE This may be performed by the user by copying existing message text and pasting into a new Chat Message R6 30 1 The user shall have the option to forward a single sent or received Group Chat Message or multimedia content to one or more contacts NOTE This function may be executed using the copy and paste text editor function of the device US6 31 As a user want to switch to a voice or video call with one of the Group Chat participants by selecting one person from the participants list and initiating the call NOTE During the Voice or Video Call the user may make use of the Group Chat application R6 31 1 The user shall have the option to easily access and make a voice call to one of the Group Chat participants After the call has ended the user interface should return to the Group Chat Conversation R6 31 2 The user shall have the option to easily access and make a video call to one of the Group Chat participants After the call has ended the user interface should return to the Group Chat Conversation V2 0 Page 79 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document US6 32 As a user want to be able to answer any incoming voice or video call during a Group Chat Conversation and resume the Group Chat when the call is finished NOTE During the Voi
110. ber Contact Card The details of a single contact which are displayed whenever a contact is selected from the contact list co A list of all the content exchanged between parties of a conversation Delivery eT l l i Indication that a message was successfully received by the B Party device Notification A duration parameter set by the operator which triggers the RCS application to DELIVERY a nee ie perform an action if the delivery notification of the receiving device has not TIMEOUT i n i been confirmed within the set time Developer Application owner Developer ID ID assigned to application owner It is not the same as the App ID Device Wiping Removing user specific data from the device hed Indication to the A Party that the B Party s device has displayed the message Notification y y pay ge Emoji are picture characters that is characters presented as pictographs a images of things such as faces weather vehicles and buildings food and Emoji i drink animals and plants or icons that represent emotions feelings or activities A graphical mood element that technically is corresponding with a text string Emoticon The text string is conveyed by the standard and interpreted on UI level and replaced with the corresponding graphical element V2 0 Page 8 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document Term Description contains technical an
111. c Note Star Clock Pizza Money Sheep Pig Sun Rain Cloud Umbrella Aeroplane Birthday Cake Party Film Gift Phone Wave Big hug Non confidential Character sequences L o b or u o u w r lt B U or Z r m ar 8 D gt lt 8 0 or O pi or PI mo or MO bah or BAH st or ST um or UM pl or PL Examples describing graphical renditions A heart A pint of beer A heart broken in two A smiling face with rockstar fingers A face with eye patch A face with wobbly mouth and spinning eyes A face with clapping hands A small penguin A semi quaver A gold star A clock face A slice of pizza or a whole pizza Coins or notes or coins and notes A sheep A pig s face A shining sun A cloud with rain or cloud with rain drop An open umbrella A plane A cake with candles A face wearing a party hat and blowing a party blower A roll of film or strip of film A gift wrapped present with bow A hand receiver with cable A face with hand waving A face with hands hugging itself Page 165 of 166 GSM Association Non confidential RCS Common Core 1 1 Service Description Document A 3 Unicode Standard Emoji Emoticons The list of required Emoji that must be graphically rendered and offered to the user and the mapping to relevant Unicode blocks is detailed in document joyn Blackbird Unicode S
112. call CS VoLTE RCS IP Voice Call while the voice call shall continue seamlessly on the same voice bearer NOTE The transmitted Video Share cannot be recorded by any user R12 3 2 OM In case the underlying voice call is terminated Video Share shall be terminated as well US12 4 As a user when receiving a video share request i e user B want to decide whether to d Decline the incoming video share request and continue with a plain voice call e Accept the incoming video share request without sending my camera view or f Accept the incoming video share request and sending also my camera view R12 4 1 OM The receiver user B shall be able to reject an incoming video share and the voice call continues R12 4 2 OM The receiver user B shall be able to accept an incoming video share i e no auto accept without initiating a video share from their side R12 4 3 OM The receiver user B shall be able to accept an incoming video share i e no auto accept with initiating a video share from their side as well R12 4 4 OM The sender shall user A be notified accordingly about the selection of the receiver user B i e accepting or rejecting the video share service If the receiver user B decides to initiate a video share service back to the originator V2 0 Page 126 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document user A the originator is not prompted to ac
113. can be realised by considering the sections 2 2 1 and 3 8 of RCC 07 Note that as per RCC 07 it is not possible for a device to simultaneously allow VoLTE and RCS IP voice call In case both VoLTE CS and RCS IP Voice Call capabilities are available simultaneously dual registration case VoLTE CS shall prevail V2 0 Page 115 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document NOTE The RCS IP Voice Call term is equivalent to the Wi Fi Voice term In this section the term RCS IP Voice call is used 10 3 2 Technical Implementation of User Stories and Service requirements V2 0 R10 13 1 The requirements for user story US10 1 shall be implemented as per PRD IR 92 For the use cases and requirements where the companion video service to VoLTE is mentioned PRD IR 94 shall be followed R10 13 2The requirements for user stories US10 2 and US10 3 shall be realised as described in sections 2 2 1 and 3 8 of RCC 07 It is left up to the service provider policy and implementation to decide how an incoming call terminates using CS VoLTE or RCS IP Voice Call The RCS telephony tag as defined in section 2 4 3 of RCC 07 may be used for this Note the parameter Voice_Domain_Preference_E_ UTRAN described in section 2 9 1 of RCC 07 shall be taken into account The possibility to provide QoS of any kind is down to service provider s policy and implementation R10
114. cations shall be stored on the network and forwarded once the sending device is online US7 4 As a user want the option to resize pictures before transferring the file in order to limit transfer volume memory need and transfer time NOTE resize means changing the picture size to either a high medium and low size of the picture R7 4 1 OM Selecting a picture file format that can be rendered by the sending device shall offer the option to resize the picture to smaller file size in order to save memory network load and transfer time Resize means changing the picture resolution NOTE In most cases users are aware of the use of the picture on receiver side for instance whether it shall be displayed on small screens only or whether it may be printed on large scale This feature provides the user with an option to adopt to these cases US7 5 As a user want the option to resize videos before transferring the file in order to limit the transfer volume the size of storage needed and the time to transfer the file Note resize means changing the resolution to either a high medium and low format R7 5 1 OM The default resizing option proposed shall be 480p at 1200kbps R7 5 2 OM Selecting a video file which is of a resolution higher than the default resizing option shall offer the option to resize the video file Video Resolution to a smaller file size in order to save memory network load and transfer time For ea
115. ce or Video Call the user may make use of the Group Chat application R6 32 1 The user shall be able to receive a voice call when actively engaged in a Group Chat Conversation and when the voice call ends the user interface should return to the Group Chat Conversation R6 32 2 The user shall be able to receive a video call when actively engaged in a Group Chat Conversation and when the video call ends the user interface should return to the Group Chat Conversation US6 33 As a user want to send Group Chat Messages from secondary devices with identical capabilities compared to primary device capabilities As a user want my device to always be in sync with the Group Chat Messages on the network even in case of multiple devices R6 33 1 Group Chat shall support Multi Device Usage US6 34 As a user want my Group Chat messages backed up on the Common Message Store which is trusted and safe R6 34 1 All Group Chat Conversations shall be stored on the Common Message Store NOTE If the user has not been part of a Group Chat Conversation from the very beginning or left the Group Chat Conversation while other Group Chat participants continued only the part of the Group Chat Conversation between joining and leaving the Group Chat shall be stored US6 35 As a user want to restore my Group Chat Conversations from the Common Message Store e g but not limited to after wiping device or purchasing a new device R6 35 1 The user sh
116. cept or reject the video share and the stream is shown on the originator s device R12 4 5 OM Upon acceptance of user A s video stream the camera view is streamed to the receiver user B and displayed on the receiver s screen US12 5 As a user accepting an incoming video share i e user B want the incoming voice automatically on a connected headset If there is no headset connected then play the voice on my external loudspeaker R12 5 1 When an incoming video share is accepted the audio part shall be played either via a connected headset if connected or via the external loudspeaker if no headset connected US12 6 As a user sharing video when rotate i e user A B my device the correct video orientation is displayed on both ends R12 6 1 OM The device shall handle the different orientation permutations depending on how the device is rotated during a Video Share to always show the incoming video in the right orientation e g not upside down US12 7 As a user sharing live video from my camera i e user A B want to toggle between front and rear camera and upon selection video is changed without interruption if the device supports two cameras R12 7 1 The user shall be able to toggle the camera i e front back which is recording the transmitted live stream given the phone supports two cameras R12 7 2 lf the phone supports two cameras the front camera shall be active by default for transmission of t
117. ch resizing option the user shall see what the file size would be after that resizing option is applied R7 5 3 OM When a video is recorded with the specific purpose of sending using File Transfer the video shall be recorded in 480p at 1200 kbps resolution US7 6 As a user don t want to perceive a restriction in file sizes that want to transfer V2 0 Page 85 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document R7 6 1 OM The service provider shall be able to configure the File Transfer service to set a maximum file size to be accepted by the File Transfer service NOTE It is recommended that RCS operators agree on a common file size limit to ensure interoperability at least on a local level R7 6 2 The service provider shall be able to configure a warning threshold value When a user attempts to transfer a file larger than this value auto acceptance is not possible US7 7 As a user want to transfer a file to multiple users at a time within a Group Chat R7 7 1 OM File Transfer within a Group Chat shall transfer the file to all participants of the Group Chat NOTE The sender side shall only send the file once over the network in this case R7 7 2 The ability to send files shall be available independently of whether the operator supports legacy Group Chat or not NOTE Any adaption from the standard Group Chat File Transfer for legacy non RCS contacts i
118. cial Document RCC 61 RCS Common Core 1 1 Service Description Document US5 9 As a user I want to be notified at any time my device receives a new Chat Message R5 9 1 OM On receiving a message the user shall be notified with graphical and sound elements similar as the device notifies of incoming SMS messages if not stated differently in this requirements document US5 10 As a user want notifications of rapidly sequenced incoming Chat Messages intelligibly aggregated and counted R5 10 1 R5 10 2 R5 10 3 R5 10 4 R5 10 5 For audio notifications device audio related settings shall prevail Rapid sequence of incoming Chat Messages in one Conversation shall be consolidated into one audible notification per Conversation Consolidation of visual notifications is not affected On selection of the visual notification for one or more new message s in a single Chat or Group Chat conversation the user shall be forwarded to the respective Chat Message and the visual notification shall be permanently removed from the notification centre or bar On selection of the visual notification for two or more new messages from different Chat or Group Chat Notifications the user shall be forwarded to the list of Chat or Group Chat conversations In this case the unread message visual identifier shall be removed once the last new message was read Alternatively the OEM may handle it differently on the device e g the visual notificatio
119. coming IP Video request is declined the CS call continues The CS call is dropped only once the IP Video call is accepted Implication on call logs and charging are noted but for each operator to deal with individually whether to accept this experience or not allowing to upgrade to an IP Video Call while on CS call US12 14 As a user during a voice call all bearers accepting an incoming IP video call I i e user B want the incoming voice automatically on a connected headset If there is no headset connected then play the voice on my external loudspeaker R12 14 1 When an upgrade to an IP video call is accepted the audio part shall be played either via a connected headset if connected or via the external loudspeaker if no headset connected US12 15 As users in an IP video call we want to continue the transmission of the video as long as possible under changing connectivity situations delivering a high quality and lip sync experience R12 15 10OM In case during an ongoing IP video call one user moves out of LTE coverage the transmission of the video media part of the IP Video Call should be maintained if network conditions allow R12 15 2 In case the transmission of the video cannot be maintained when one user moves out of LTE coverage an automatic establish of a Video Share session shall be initiated by the party moving out of the LTE coverage if capabilities allow NOTE Existing flows for initiating and accepting Video Sha
120. d 3 6 of RCC 07 NOTE In line with the requirements in this document and IP Video Call page 118 in case the call is an end to end VoLTE call covered in PRD IR 92 and the VILTE service covered in PRD IR 94 is available confirmed via capability exchange video share shall not be available to the user e Upgrade to video call Implemented by upgrading the existing call to an RCS IP video call service as described in section 3 9 of RCC 07 and addressed in IP Video Call page 118 V2 0 Page 132 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document NOTE In line with the requirements in this document and IP Video Call page 118 in case ViILTE covered in PRD IR 94 is available confirmed via capability exchange the upgrade to video call shall be performed using ViLTE e Image share share a picture during a call Implemented via the RCS image share service as described in section 3 6 of RCC 07 e Sharing any file during a call Implemented via the RCS File Transfer service as described in section 3 5 of RCC 07 e Exchange messages Implemented via either RCS Standalone Messaging service or the RCS 1 to 1 Chat service as described in sections 3 2 and 3 3 respectively of RCC 07 e Location push Implemented via the RCS location push service as described in section 3 10 of RCC 07 NOTE 1 Common to all the services and before initia
121. d and how it is handled e g with support of video mail box or voice mail box R11 4 3 OM For acceptance the receiver shall have the option to answer the incoming IP video call with or without transmitting their own camera view back to the sender US11 5 As a user answering an incoming IP video call I i e user B want the incoming voice automatically on a connected headset If there is no headset connected then play the voice on my external loudspeaker R11 5 1 When an upgrade to an IP video call is accepted the audio part shall be played either via a connected headset if connected or via the external loudspeaker if no headset connected US11 6 As users in an IP video call we want to experience in ideal end to end coverage situation a high quality and lip sync video experience V2 0 Page 119 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document R11 6 1 OM The IP video call should be connected with guaranteed video quality when available operator preferred connectivity method R11 6 2 OM lf guaranteed video quality is not available the IP video call should be connected with at a minimum best effort video quality operator less preferred connectivity method US11 7 As users in an IP video call we want to continue the transmission of the video as long as possible under changing connectivity situations delivering a high quality and lip sync experience R11 7
122. d functional terms Externa Speaker on the device which amplifies the audio of the call when activated Loudspeaker Feat re Ta A IARI Tag assigned to a RCS functionality allowing to identify and route the g RCS traffic invoked by those apps through APIs Front Camera Camera placed on the display side of a communication device nacia nevica A device or interface not currently active in a multi device scenario or Interface Interconnected An RCS Service that can be accessed between users of network operators RCS Service supporting the same RCS Service capabilities Any entity that provides RCS Service capabilities to a user e g browser Interface l based app based natively implemented IMSI International Mobile Subscriber Identification A operator messaging service whereby the different message types are Integrated proposed to the end user threaded together in a conversation and can be Messaging changed by the user In this experience the message type used to deliver a message is indicated to the user Messagin Associated with any of the services listed in R9 3 4 and includes all types of ging messages files content new message notifications previews icons and event ee message status notifications sent and received MNO Mobile network operator Multi Device RCS Service that enables a user to register more than one device under a Support single identity MSISDN Mobile Sub
123. dditional UX configuration parameter VIDEO UX as described in Table 4 R11 18 5 Requirements R11 2 3 R11 2 4 and R11 2 5 shall be implemented locally in the device and consequently make the relevant capabilities available or not during capability discovery V2 0 Page 122 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document NOTE For the cases the video shall not be initiated the implementation shall follow the procedures described in section 2 2 2 of PRD IR 94 which is applicable both to TE1 and by endorsements to TE2 R11 18 6 Requirement US11 3 including R11 3 1 shall be implemented locally in the device The Technical Enabler depends on network conditions supported services and client device configuration R11 18 7The realisation for requirement R11 3 2 including is covered in section 11 3 1 NOTE requirement R11 3 2 is not implementable if TE1 is used R11 18 8 For requirement US11 4 the following shall be considered e TE1 Section 2 2 2 of PRD IR 94 e TE2 Section 3 9 4 2 2 of RCC 07 R11 18 9 Requirements R11 4 3 and US11 5 shall be implemented locally in the device R11 18 10For requirement R11 6 1 section 2 2 2 of PRD IR 94 shall be considered and for requirement R11 6 2 sections 2 2 1 2 7 1 2 2 and 3 9 of RCC 07 shall be taken into account NOTE In all cases the decision to provide guaranteed or best effort QoS to the video stream is u
124. dential Official Document RCC 61 RCS Common Core 1 1 Service Description Document R7 12 3 OM Chat of Group Chat Conversations shall be sorted descending according to the time stamp of the last action e g but not limited to a received File Transfer Audio Message or Geolocation Push within the conversation i e the Conversation with the latest event timestamp shall be on top of the list R7 12 4 OM Chat or Group Chat Conversations with unread events any event that is received within the Chat Conversation including but not limited to Chat Messages received files received Geolocation Push received Audio Messages shall be marked accordingly e g by display of a subject line in bold font and or a unread message counter US7 13 As a user want to see incoming files as a thumbnail preview or generic icon if content cannot be rendered on a receiving device including fil size indication As a user want to trigger file download to my device by selecting the thumbnail preview As a user want to be in control of the acceptance of the File Transfer individually or for all File Transfer events R7 13 1 In case File Transfer Auto Accept is set to off R7 13 1 1The incoming File Transfer presents a thumbnail preview of the file including file size on the receiving device first R7 13 1 2The thumbnail preview shall be a preview of the actual picture if the file type is a picture in a format that can be rendered by
125. der Extension Node Values N A V2 0 Page 59 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document Type property of the node is urn gsma mo gcc clientControl 1 0 Ext Post reconfiguration actions The client should be reset and should perform the complete first time registration procedure following a reconfiguration Associated HTTP XML characteristic type Ext 4 3 3 Capability Discovery To realise the behaviour specified in this Operator Messaging chapter section a client must be able to indicate whether a combined messaging UX is provided to the user integrated seamless messaging user Thus a new SIP OPTIONS tag and Presence service id is defined for clients to be able to convey the Combined Messaging UX capability Clients shall indicate their Combined Messaging UX capability in accordance with their ability to manage xMS messaging A client configured for Integrated Messaging or Seamless Messaging shall advertise the Combined Messaging UX capability as long as it is able to manage both xMS and RCS messaging If the client does not own the capability to manage the xMS service due to other device configurations then it shall not advertise the Combined Messaging UX Capability NOTE For the definition of the SIP OPTIONS tag a value of RCS joyn Blackbird is used to ensure interoperability with devices of this RCS profile RCS service Combined g 3gpp iari r
126. device shall hide this network behaviour from the user and simulate the experience of a permanent Group Chat showing the conversation in the Chat history and allowing any subsequent continuation The following solution shall be implemented R6 23 3 1Session related information is not shown to the user i e Chat closed shall not be displayed at the UI level V2 0 Page 77 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document R6 23 3 2Simply writing a new message and hitting Send shall be enough to continue a Group Chat that has timed out at network level R6 23 3 3When the user hits Send the Group Chat session is set up and the user message is also sent R6 23 3 4When a Group Chat is restarted no notifications of users joining shall be displayed for participants that were already part of the local participant list The Group Chat header shall show if any participant is unavailable and shall give access to details of active participants R6 23 3 5Group Chat follows up in the same Chat window keeping the full history of the session R6 23 3 6While the Chat is closed at network level the Participants list should still be expandable in order for the user to be able to see the recipients of their new message However all participants may be marked as inactive where there is no information on their availability US6 24 As a user want to maintain mult
127. e clients and this document for the most part will not differentiate between the two In those cases where implementation of a feature in a downloadable client differs from the native experience this may be described separately within the relevant section V2 0 Page 5 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document 1 2 Table of references Ref DocNumber _ Title 3GPP TS 22 140 release 10 1 Baa Multimedia Messaging Service MMS Stage 1 http www 3gpp org DynaReport 22140 htm I3GPP TS 3GPP TS 23 040 release 10 2 23 040 Technical realization of the Short Message Service SMS http www 3gpp org DynaReport 23040 htm 3GPP TS 24 167 release 10 3 BGPP TS 3rd Generation Partnership Project Technical Specification Group Core 24 167 Network and Terminals 3GPP IMS Management Object MO http www 3gpp org DynaReport 24167 htm 4 CAB_TS OMA Converged Address Book CAB Specification Approved Version 1 0 13 November 2012http www openmobilealliance org GSMA PRD IR 92 IMS Profile for Voice and SMS 5 PRD IR 92 Version 7 1 18 September 2013 http www gsma com GSMA PRD IR 94 IMS Profile for Conversational Video Service 6 PRD IR 94 Version 6 1 23 September 2013 http www gsma com GSMA PRD RCC 07 version 6 0 Rich Communication Suite 5 3 Advanced Communications Services and Client Specification 28
128. e Transfer including but not limited to 1 to 1 Chat Group Chat Contact Card and Gallery US7 3 As a user want to see the status of any file sent including those which have not been delivered yet R7 3 1 File Transfer shall support delivery status notifications per individual file sender device R7 3 1 1 File Transfer Pending waiting to transfer the file to the network e g queuing on device V2 0 Page 84 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document R7 3 1 2 File Transfer in progress progress bar that indicates the transfer progress of the file transmission from sending device to the network R7 3 1 3 Cancelled the sender shall have the option to cancel the File Transfer during the File Transfer process R7 3 1 4 File delivered transmission of the File Transfer request has been successfully completed to the receiving network R7 3 1 5 File downloaded Automatic or user initiated download of file is complete R7 3 1 6 File Transfer failed The expected outcome of the operation could not be confirmed by the network NOTE In this case File Sent or File Delivered status notification has not been received and the device does not attempt to transfer the file anymore The failed File Transfer event may be re triggered manually by the sender R7 3 2 OM If the sending device is offline at the time a notification is received notifi
129. e Transfer section page 84 Audio Messages shall be stored on a central operator storage in accordance with requirements defined the File Transfer section page 84 Any Audio Messages shall be available on secondary devices and interfaces in accordance with requirements in the File Transfer section page 84 and requirements specified in the Messaging for Multi Device section page 102 Audio Messages shall display an Audio Messaging specific icon in the Chat or Group Chat Conversation The Audio Message icon shall provide a clear visual association with the Audio Message file type so that a user shall easily identify itas a sound file and shall understand that clicking on it will lead to download and or playback of an Audio Message R8 3 4 1 This icon shall be visually distinguishable from a music file icon R8 3 5 R8 3 6 R8 3 7 R8 3 8 Audio Messages shall be available for playback from the Chat or Group Chat conversation by sending and receiving parties OM Audio Messages shall be saved in the conversation history along with Chat messages and files in a chronological order as per ordering requirements specified in Chat and Group Chat sections OM Audio Messages shall be displayed with information on the message s time and date and duration OM In the case of Multi Device all requirements in the File Transfer section page 84 and in the Multi Device Messaging section page 102 shall apply Page 98 of 166 GSM Assoc
130. e able to activate or not activate the RCS IP Voice Call service using the provisioning process of a secondary device R10 7 2 If activated during the provisioning process secondary devices which are data only devices shall support RCS IP Voice Call either over non cellular access only or non cellular access and cellular data bearer based on individual configuration of the service provider US10 8 As a service provider may want to allow multi party voice calling utilising CS VoLTE RCS IP Voice Call R10 8 1 Multi party voice calls may be offered by a service provider utilising any available call bearer CS VoLTE RCS IP Voice V2 0 Page 114 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document US10 9 As a user want to use emergency call services over RCS IP Voice Call as far as country specific regulatory requirements require R10 9 1 Emergency call services shall be supported as regulatory requirements exist today or are expected to come into place in the relevant territories US10 10 As a service provider may want to allow supplementary services for RCS IP Voice Calls such as Calling Line Identification Presentation CLIP Call Waiting CW Call Hold Call Forward Busy CFB Call Forward Unreachable Call Forward No Reply and Conference Call R10 10 1 Supplementary Services such as Calling Line Identification Presentation CLIP Call Waiting CW Call
131. e actions shall not be invoked by the client The default value should be set to 0 seconds if the parameter is not provided NOTE A recommended default value of 300 seconds is used in case the parameter is not provided FT HTTP CAP This parameter controls whether 1 to 1 File Transfer is Optional ALWAYS ON available to all contacts supporting File Transfer via Parameter HTTP regardless of their online status 1 or only to It becomes those contacts that are online 0 mandatory when MESSAGING UX is set to 1 Table 21 Common Core Client Control Configuration Parameters These client control parameters will be placed in a new Client Control sub tree defined in this specification V2 0 Page 57 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document ra N lt X gt clientControl H delivery Timeout Wee ee 4 ftHTTPCapAlwaysOn Figure 13 Client Control MO sub tree The associated HTTP configuration XML structure is presented in the table below lt characteristic type clientControl gt lt parm name deliveryTimeout value X gt lt parm name ftHTTPCapAlwaysOn value X gt lt characteristic type Ext gt lt characteristic gt Table 22 ClientControl sub tree associated HTTP configuration XML structure Node lt x gt ClientControl Common Core related parameters used to control the client b
132. e again R8 1 11 The sender shall be able to cancel the sending of an Audio Message before transfer is complete in accordance with requirements in the File Transfer section page 84 R8 1 12 lf a sender is interrupted when they are recording an Audio Message e g by an incoming call then the recording shall stop and the recording that was made shall be held in the device for later use R8 1 13 OM Sent Audio Messages shall be displayed and available for playback from a Chat Conversation which is associated with the participant s concerned R8 1 13 1 Audio Message recording shall be limited to a maximum length of ten minutes NOTE Operators should consider this maximum length when setting the maximum file size supported by a File Transfer US8 2 As a user want to be able to receive and listen to Audio Messages that are shared with me as part of a 1 to 1 Chat or Group Chat session 8 2 2 Notification on Receiving Audio Messages R8 2 1 Notifications on reception of an Audio Message or preview icon shall be in line with the according requirement s in the File Transfer section page 84 R8 2 2 Anew Audio Message notification may look different from a new Chat Message or File Transfer notification in order to indicate it as being an Audio Message R8 2 3 Sorting of Chat and Group Chat Conversations on new incoming Audio Messages shall be in line with the according requirement s in the File Transfer section page 84 R8 2 4 Selecti
133. e in the end to end user scenario Due to the desire of operator specific configurability of those technologies combinations can be clustered into two profiles RCS IP Voice ViLTE ViLTE ViILTE ViIP CS VS VS VS VS VS VS RCS IP Voice ViIP ViLTE VS VS ViIP ViIP Table 30 VIDEOSHARE PROFILE RCS IP VIDEO CALL UPGRADE FROM CS 0 V2 0 Page 125 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document RCS IP Voice Wi Fi Voice ViLTE ViLTE VILTE ViIP ViILTE ViIP cS ViIP ViLTE ViIP ViIP ViIP ViIP RCS IP Voice ViIP ViLTE ViIP ViIP ViIP ViIP Wi Fi Voice Table 31 VilP PROFILE RCS IP VIDEO CALL UPGRADE FROM CS 1 12 2 2 1 Video Share Video Share is offering a way to share live video during an ongoing call without affecting the underlying voice call A main characteristic is a non lip sync experience between voice and video US12 3 As auser in a voice call i e user A want to have the ability share a live i e the camera view or recorded video from my in call screen with the other participant of the call i e user B whenever it is possible While sharing the video is delivered as a real time stream to the receiver s screen the sound is still delivered via the ongoing Voice Call R12 3 1 OM A user shall be able to stream a Video Share to the other conversation party during an ongoing voice
134. e pertaining objects from the Common Message Store and by the device not deleting messages on the device that it no longer receives after synch with the Common Message Store R9 5 33 2Requirement R9 3 24 shall be implemented locally on the device by the device not deleting on the device or in the Common Message Store any content that the user did not specifically select for deletion R9 5 34 Requirement R9 3 25 shall be implemented locally on the device R9 5 35 Requirement R9 3 26 is covered by the procedures described in section 3 3 4 1 7 of RCC 07 NOTE To be sure to receive all messages of the conversation the switching device would have to keep synching with the CMS until the new session is established R9 5 36 Requirement R9 3 27 is covered by the procedures described in section 3 3 4 1 7 of RCC 07 R9 5 37 Requirement US9 4 and R9 4 1 are covered by the RCS infrastructure The IMS and Application Server infrastructure used for RCS does not put technical restrictions on the number of parallel sessions nor does it restrict such parallel sessions to a particular device Limitations on parallel sessions may be imposed by an operator policy applied in the network or due to resource constraints in device or network V2 0 Page 112 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document 10 IP Voice Call 10 1 Description IP Voice Call describes the behaviour of voice
135. e proposed File Transfer Service to be used for sending files shall be determined by the registration status to RCS platform of the sender A Party and if the B Party is a known RCS user V2 0 Page 52 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document R4 16 2 lf the A Party is registered to RCS online R4 16 2 1RCS File Transfer shall be the default service for outbound files proposed by the device logic for recipients being known as RCS capable contacts irrespective of their connectivity status R4 16 2 2MMS shall be the default File Transfer Service for outbound messages proposed by the device logic for recipients being known or detected as not RCS capable R4 16 3 lf the A Party is not registered to RCS offline R4 16 3 1 Any files sent to a B Party who is known as an RCS user shall be RCS File Transfer locally queued and sent once the RCS connectivity is restored In this case the A Party shall be informed about the offline status by the device appropriately R4 16 3 2Any Files sent to a B Party who is not known as an RCS user shall be sent as MMS In case no data connection is available MMS shall be locally queued the A Party shall be informed about the offline status by the device appropriately and the file will be sent once mobile data is available again File Transfer 2 FT HTTP_CAP_ALWAS_ ON 1 Selected File Transfer Service
136. e requirement of user story US6 18 for display notifications is implemented as defined in section 3 4 4 1 5 of RCC 07 R6 37 19The requirements for user story US6 19 shall be implemented locally on the device For acceptance of Group Chat sessions the client shall apply the behaviour as defined by the configuration parameters IM SESSION AUTO ACCEPT GROUP CHAT and IM SESSION START The client shall not apply any UI procedures for the acceptance of the delivery of single messages R6 37 20 Sending of Multimedia in a Group Chat as defined in the requirements of user story US6 20 is done R6 37 21 For the requirements in user story US6 21 the client shall support the following procedure e tis the responsibility of the Messaging Server to deliver messages in the correct order so the Client can rely on it when sorting messages The client shall interleave the sent and received messages in the chronological order e After the client has synchronized with the Common Message Store successfully then messages shall be sorted in accordance with the time indicated in the CPIM DateTime header value received with message from the Common Message Store R6 37 22 The requirements of user story US6 22 shall be implemented locally on the device R6 37 23The requirements of user story US6 23 shall be implemented locally on the device based on the Group Chat life cycle definitions in section 3 4 4 of RCC 07 R6 37 24 The requirements of user stories US6
137. e the Chat and Group Chat applications on the device but there shall be other service entry points as well This chapter describes the User Stories Service Requirements and Technical Implementation details for the core File Transfer service and all features around the core Geolocation Push allows a user to share their current position or selected location with one or more RCS contacts 7 2 User Stories and Feature Requirements US7 1 As a user want to transfer files to Contacts and receive files from other RCS users As a user want to transfer and receive a file of any file format NOTE Any file format can be selected and transferred irrespective of the receiving device capabilities of representing the content in an appropriate way R7 1 1 OM File Transfer shall allow transfer of any files from a sending device to one or more recipients NOTE This document describes the File Transfer functionality between RCS users Other Contacts without RCS may have less functionality available Please refer to Operator Messaging page 36 R7 1 2 OM File Transfer shall be capable of transferring exactly one file at a time NOTE The user interface of a device may want to allow multiple selection of files for File Transfer and then process these files as separate File Transfer jobs US7 2 As a user want to transfer a file from multiple service entry points on my device R7 2 1 There shall be a number of service entry points to Fil
138. ed in Security against Malware page 161 US2 7 As a user want to have access to the text displayed as User Message and or End User Confirmation Request at any time after being provisioned to the service R2 7 1 The text displayed as User Message and or End User Confirmation Request shall be accessible for the user after the user has started using the service e g in Messaging Settings 2 2 4 Secondary Devices US2 8 As a user want to use RCS services on other RCS enabled devices other than my primary device R2 8 1 Any device for which there is a compatible RCS application shall become a secondary device R2 8 2 When a user wants to use their primary identity in a second or subsequent device they shall follow a specific authentication process R2 8 3 If the application is to be shared by several operators it shall request the user during the secondary device s authentication process to choose among the available options As an alternative the application could be operator and country specific therefore not needing to request this information R2 8 4 During the secondary device s authentication process the user shall be prompted to type in a valid MSISDN R2 8 5 After successful completion of R2 8 4 a password shall be sent over SMS to the user s primary device R2 8 6 n case the user enters and sends an invalid MSISDN in R2 8 5 the UI shall respond according to R2 9 1 V2 0 Page 18 of 166 GSM Ass
139. ed in RCC 07 shall be sent to the network at the first possible occasion R2 11 9 When the user re enables an RCS client a HTTP configuration request will be done to verify whether the available version of the RCS configuration parameters is still valid R2 11 10 Requirements R2 3 9 to R2 3 14 shall be implemented locally on the device with the operator having the possibility to disable the RCS client as indicated in requirement R2 3 14 by setting the RCS DISABLED STATE configuration parameter in a provided configuration document to 1 as described in section 2 3 3 2 of RCC 07 For R2 3 11 SIM swap shall be handled as described in section 2 2 and 4 2 1 of R2 11 11 The user consent before use of the service described in user story US2 4 shall be realised through the mechanism for providing User Messages in the HTTP configuration described in section 2 2 3 of This mechanism shall be supported by the RCS clients and may be used upon the service provider s discretion Page 23 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document R2 11 12As described in section 2 2 3 of the User Message mechanism supports requirements R2 4 1and R2 4 4 R2 11 13 Requirements R2 4 2 and R2 4 5 shall be implemented locally on the device NOTE The retry algorithm described is to be realised in the device An operator can V2 0 opt for more retries through the Provisioning Push mechanism
140. ef urn 3Aurn 7 3A3gpp application ims iari joyn intmsg Messaging UX Table 27 SIP OPTIONS tags for Messaging Modes The following lt service description gt elements will be used for Capability Discovery via Presence as extension to the definitions in section 2 6 1 2 of RCC 07 Combined Messaging UX Service id org 3gpp urn urn 7 3gpp application ims iari joyn intmsg Version 1 0 Contact address type tel SIP URI 4 4 Technical Implementation of User Stories amp Feature requirements R4 17 1 The requirements listed under user story US4 1 shall be implemented locally on the client R4 17 2 The requirements listed under user story US4 2 shall be implemented locally on the client based on the submission delivery and display status technology of the various messaging technologies Note the service provider is able to provide a display notification for MMS via Read Reports V2 0 Page 60 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document R4 17 3 R4 17 4 R4 17 5 R4 17 6 The requirements listed under user story US4 3 the operator shall implement message revocation for 1 to 1 Chat as defined 3 3 4 1 10 of RCC 07 The requirements listed under user story US4 4 shall be implemented locally on the device based on the capability discovery result Requirement R4 4 1 shall be implemented as defined in section 4 3 3 The requirements listed under user st
141. efined in requirements of user story US7 13 is defined is controlled via the FT AUT ACCEPT parameter defined in section A 1 5 of RCC 07 The requirements of the user story US7 12 related to thumbnail preview are implemented for File Transfer over MSRP as defined in section 3 5 4 of RCC 07 and for File Transfer over HTTP as defined in section 3 5 4 8 RCC 07 For File Transfer over MSRP to offline users store and forward thumbnails are not supported as defined in section 3 5 4 7 2 of RCC 07 R7 26 14The requirements of user story R7 13 5 shall be implemented locally on the device R7 26 15The transfer format for personal cards of user story US7 14 is defined in section 3 5 4 9 1 of RCC 07 R7 26 16 The requirement to resume interrupted File Transfers of user story US7 15 shall only be supported if File Transfer over HTTP is used as defined in section 3 5 4 8 of RCC 07 R7 26 17The file size limits defined in the user story US7 16 are configured via the FT MAX SIZE parameter defined in section A 1 5 of RCC 07 R7 26 18The user story US7 17 will be implemented as defined in section 3 5 4 1 of RCC 07 R7 26 19 The administration of File Transfers defined in user story US7 18 US7 19 and US7 20 in conjunction with the Common Message store is defined in section 3 5 4 8 6 of RCC 07 for File Transfer over HTTP and RCC 09 for File Transfer over MSRP R7 26 20 The requirements of the user stories from US7 22 to US7 25 are imp
142. ehaviour are placed under this interior node Status Occurrence Format Min Access Types Required One Table 23 ClientControl MO sub tree addition node e Values N A e Type property of the node is urn gsma mo gcc clientcontrol 1 0 e Associated HTTP XML characteristic type clientControl Node lt x gt ClientControl deliveryTimeout Leaf node that configures on a device the timeout for the reception of delivery reports after which a context specific actions are invoked The node is optional and if not provided the default value of 300 seconds will be used Status Occurrence Format Min Access Types Required ZeroOrOne int Get Replace V2 0 Page 58 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document Table 24 Client Control MO sub tree addition parameters deliveryTimeout Values integer value defining the timeout to be used in seconds when set to 0 the timeout shall not be used as trigger for a capability check Type property of the node is urn gsma mo gcc clientControl 1 0 delivery TimeoutPost reconfiguration actions As the client remains unregistered during configuration there are no additional actions apart from de registering using the old configuration and registering back using the new parameter Associated HTTP XML characteristic type deliveryTimeout Node lt x gt ClientControl ftHT TPCapAlwaysOn Leaf node that d
143. either a link that opens a map application on the web or a map image 7 3 Technical Information 7 3 1 Overview The File Transfer service is provided as defined in section 3 5 of RCC 07 There are a number of technologies to provide the File Transfer user experience It is a service provider option which File Transfer technology is deployed The selection of the transfer technology for files is derived by the client as result of the capability discovery as defined in sections 2 6 1 1 2 2 6 1 2 3 and 3 5 4 8 1 of RCC 07 7 3 2 Technical Implementation of User Stories and Service requirements R7 26 1 For the requirements of user story US7 1 the following definitions apply e The File Transfer service shall be offered to the user if the device configuration authorizes the service via the PROVIDE FT parameter defined in section A 1 5 of RCC 07 e The ability of the user to send files to a contact depends on the result of the capability discovery as defined in section 2 7 of RCC 07 V2 0 Page 92 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document R7 26 2 The requirements of user story US7 2 shall be implemented locally on the device R7 26 3 The requirements of user story US7 3 shall be implemented as follows The implementation depends on the file transport technology used Pending For File Transfer over MSRP when the user presses ENTER to send the mes
144. eiving Audio Messages 8 3 Technical Information 8 3 1 Overview 8 3 2 Requirements matching 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 Requirements matching IP Voice Call 10 1 Description 10 2 User Stories and Feature Requirements 10 3 Technical Information 10 3 1 Overview 10 3 2 Technical Implementation of User Stories and Service requirements IP Video Call Non confidential 54 55 60 60 61 61 61 68 68 68 71 71 71 81 81 81 84 84 84 92 92 92 95 95 95 96 97 98 99 99 99 102 102 102 107 107 109 113 113 113 115 115 116 118 Page 3 of 166 GSM Association Official Document RCC 61 RCS Common Core 1 1 Service Description Document Non confidential 11 1 Description 118 11 2 User Stories and Feature Requirements 118 11 3 Technical Information 122 11 3 1 Overview 122 11 3 2 Technical Implementation of User Stories and Service Requirements 122 12 In Call Services 124 12 1 Description 124 12 2 User Stories and Feature Requirements 124 12 2 1 General 124 12 2 2 Live Video 125 12 2 3 Image Share 129 12 2 4 Share any file during call 130 12 2 5 Both Exchange messages 131 12 2 6 Location Push 132 12 3 Technical Information 132 12 3 1 Overview 132 12 3 2 Detailed requirements realisation 133 13 API Extensions 136 13 1 Description 136 13 2 User Stories and Feature Requirements 137 13 3 Technic
145. emoved from a device or otherwise permanently deactivated it shall attempt to inform the service provider R3 3 11 A triggered removal shall be applied when all of the following conditions apply R3 3 11 1A RCS contact is manipulated by the user in such a way to trigger a capability and availability check e g in a group chat picker and its RCS capabilities are older than an operator set parameter and the operator does not request a periodic polling of the capabilities of contacts with obsolete capability information R3 3 11 2The response to the capability exchange is inconclusive R3 3 12 When the RCS application on the device is disabled by the operator the contact s RCS capability and availability indications associated with the RCS application shall be removed from all associated device UI s on the user s device R3 3 13 When the RCS application on the device is uninstalled by the user the contact s RCS capability and availability indications associated with the RCS application will be removed from all associated User Interface s on the user s device Technical Information Overview Capability Discovery and Service Availability shall be realised based on two main Technical Enablers TE1 TE2 SIP Options Exchange as specified in RCC 07 Sections 2 6 2 6 1 1 2 7 2 7 1 1 Presence Based Exchange as specified in RCC 07 Sections 2 6 2 6 1 2 2 7 2 7 1 1 3 7 4 A 1 A1 1 A 2 8 The two implemen
146. en the preferred service changes to Chat L3 New or Existing START L1 Is A L2 Is Valid Conversation party RCS ves gt B party Cap ves gt Chat Composer f Displayed Opened Online available New Cap check Is B xMS Composer displayed while checking Cap Noii received in meantime Includes NO non RCS YES i capable Y xMS Composer N aaa N GO TO FLOW 4 2 Displayed i e treated as Ongoing conversation if messages have been sent or received in the meantime Figure 6 Initial Technology Selection Logic When Entering a Conversation IM_CAP_ALWAYS_ON 0 4 2 3 2 During an ongoing xMS conversation R4 13 1 2 During an on going xMS conversation the proposed Messaging Service shall change according to Figure 8 including but not limited to the following cases R4 13 1 3 When a chat message or RCS File is received from the B Party R4 13 1 4 When the B party with Integrated or Seamless messaging is discovered as RCS online xMS Composer gt Open in Ongoing Conversation START L6 Does B party have L2 Has new Chat msg been Li Is A party RCS Online L7 X L8 New YES gt B party Cap check Has A party just come Online No change to composer V2 0 Page 44 of 166 GSM Association Non confidential Official Document RCC 61 RCS Commo
147. epresentation of Operator Messaging to the user o Common Requirements for Operator Messaging o Variant 1 Integrated Messaging o Variant 2 Seamless Messaging e Client logic to propose the desired Messaging service o Offline experience for messaging IM_CAP_ALWAYS_ON 0 Offline experience for sending files FT_HTTP_CAP_ALWAYS_ON 0 Online experience for messaging IM_CAP_ALWAYS_ON 1 Online experience for sending files FT_HTTP_CAP_ALWAYS_ON 1 Seamless Messaging based on sender s device connectivity and RCS registration Oo O00 0 In general we distinguish between two different integration options Seamless Messaging and Integrated Messaging e In Seamless Messaging the user sends a message or sends a file not being aware of which Messaging Service is being used and having no influence on how the message or file is transferred e In Integrated Messaging the user has one Inbox for various Operator Messaging Services and the various service messages are all threaded into one conversation but the Messaging Service that is proposed to convey the message or file is indicated to the user By user action the proposed Messaging Service can be changed whenever alternatives are available During the Device Provisioning Process the operator sets parameters to configure the service in the way he wants to offer the service 4 2 User Stories and Feature Requirements US4 1 As a user want to see all messages and files exc
148. er prompts for OTP as defined in section 2 3 2 of R14 4 6 3For the configuration of additional devices sharing an identity there are a number of user interactions involved The primary device holding the user s identity to be federated with the additional device may support a procedure to enable the user consent based on the external EUCR as defined in section 2 1 2 of RCC 15 The user dialogue associated with this action is in band The procedure to request the federation of the user identity of a primary device via the HTTP s based client configuration mechanism for alternative devices sharing a user identify as defined in section 2 3 5 of Page 148 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document RCC 07 requires user prompt for MSISDN and service provider indication on the additional device In addition the user may need to enter an OTP ora PIN as defined in section 2 5 10f and 2 1 2 of RCC 15 This full user interaction flow is in band The reception of the OTP on the primary device via SMS as defined in section 2 5 1 of RCC 15 is out of band The user interaction for the federation consent on a primary device via the external EUCR as defined in section 2 1 2 of RCC 15 is in band The user interaction for the input of a PIN on the primary device as defined in section 2 3 3 4 2 3 of RCC 15 is in band R14
149. escribes whether the File Transfer via HTTP capability needs to be on independently of whether or not the other end is registered For example this can be used by service providers preferring the user experience of 1 to 1 File Transfer to offline users over the use of xMS based messaging It is required to be instantiated if a service provider enables the Integrated Messaging experience Status Occurrence Format Min Access Types Required ZeroOrOne bool Get Replace Table 25 Client Control MO sub tree addition parameters ftHTTPCapAlwaysOn Values 0 File Transfer via HTTP can be used only to File Transfer via HTTP capable contacts that are online 1 File Transfer via HTTP can be used with all File Transfer via HTTP capable contacts regardless of their current status Post reconfiguration actions As the client remains unregistered during configuration there are no additional actions apart from de registering using the old configuration and registering back using the new parameter Associated HTTP XML characteristic type ftHTTPCapAlwaysOn Node lt x gt ClientControl Ext An extension node for service provider specific parameters Clients that are not aware of any extensions in this sub tree e g because they are not service provider specific should not instantiate this tree Status Occurrence Format Min Access Types Optional ZeroOrOne node Get Table 26 ClientControl MO sub tree addition Service Provi
150. essage is created US5 6 As a user I want to receive text Chat Messages from my contacts R5 6 1 OM Any RCS user shall be able to receive Chat Message s that are sent to them US5 7 As a user can senda Chat Message like a text and it is just delivered B party does not need to accept the message R5 7 1 OM Chat Messages shall be received straight in the inbox no hand shake acceptance shall be required US5 8 As a user want to send text Chat Messages to my contacts even when they re temporarily offline e g device switched off expect them to receive these Chat Messages when they come online again R5 8 1 OM Incase the B Party is currently not connected to the RCS service remark offline the message s shall be delivered once the user is back registered on RCS NOTE If the B party receives the message using another service before re registering to RCS then the B party shall not be notified of the message this avoids message duplication NOTE Details of alternative delivery methods from Operator Messaging page 36 may apply R5 8 2 OM The operator shall be able to set the storage duration for store amp forward cases deferred messaging based on its own individual operator parameters NOTE The parameters may be aligned at a local level as the terminating network storage time has an impact on the sending network user s experience V2 0 Page 63 of 166 GSM Association Non confidential Offi
151. essaging for Multi Device page 102 R5 26 20 The requirements of user stories US5 22 through US5 24 shall be implemented locally on the device R5 26 21 The requirements of user story US5 25 will be implemented as defined in section 3 3 4 1 1 or 3 3 4 1 2 of RCC 07 V2 0 Page 70 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document 6 Group Chat 6 1 Description Group Chat allows users to exchange chat messages with a number of contacts This Service Description Document describes the User Stories Service Requirements Technical RCS Definition for the core chat service and all features around the core 6 2 User Stories and Feature Requirements US6 1 As a user want to create either an Open Group Chat Conversation with a selection of my contacts or a Closed Group Chat Conversation with a selection of my contacts R6 1 1 Any RCS user shall be able to create an Open Group Chat Conversation by selecting capable for this service contacts from the contact list and invite them to an Open Group Chat R6 1 2 It shall be possible to create an Open Group Chat Conversation by adding a for this service capable participant to a 1 to 1 Chat Conversation The existing 1 to 1 Chat Conversation remains in the Chat Conversation list and a new Group Chat is being created R6 1 3 Any RCS user shall be able to create a Closed Group Conversation by selecting capable for this
152. essaging service shall be capable of sharing exactly one Audio Message at a time The Audio Message shall stay within limits of the File Transfer maximum size limits as defined in the File Transfer section page 84 Interruptions in transfer of Audio Messages shall be handled as defined in the File Transfer section page 84 8 2 1 Sending Audio Messages R8 1 7 Audio Messaging shall be available from the following service entry points R8 1 7 1 It shall be possible to create and send an Audio Message to an RCS contact from an existing 1 to 1 Chat or Group Chat session R8 1 7 2 A Ul entry point of the contact card of an RCS contact shall allow the possibility of creating and sending of an Audio Message R8 1 7 3 A Ul entry point of the messaging application shall allow the possibility of creating and sending of an Audio Message R8 1 7 4 A UI entry point from the call log or call history for RCS contacts shall R8 1 8 NOTE R8 1 9 R8 1 10 allow the possibility of creating and sending of an Audio Message OM Audio Messaging within a Group Chat shall transfer the Audio Message to all participants in the Group Chat The sender side shall only send the file once over the network in this case Audio Messages are created by a simple user interaction e g pressing or holding down a soft key or button to record the message Once the soft key or button is pressed again or released the message recording is terminated and
153. eveloper want to be able to use a specific API called Multimedia session allowing two apps that have the same Feature Tag to exchange specific data R13 7 1 A multimedia session can be established only between two apps that support the same Feature Tag R13 7 2 An interface allows to check for a specific user the support of the same Feature Tag R13 7 3 An RCS enabled app using Multimedia session provides a capability that follows the regular capability discovery mechanism A B app app Multimedia SS TL Session Figure 14 Multimedia session 1 US13 8 As a developer want to be able to integrate RCS communications features within my apps through APIs This enables end users to establish a communication from their app Here are different scenarios according to developers needs R13 8 1 App to app communication The A party triggers an RCS communication from an app using the APIs In this mode A party and B party shall both have the same Feature Tag B party receives the RCS communication within this app identified by the Feature Tag V2 0 Page 138 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document A B app app IM FT Figure 15 App communication R13 8 2 App to RCS UX The A party triggers an RCS communication from an app using the APIs In this second mode B party is not required to have a specific app or service identified by
154. ew receive send and manage their Chat and xMS messages and RCS based content from devices and interfaces other than the mobile device containing the primary SIM Examples of devices include but are not limited to non native interfaces on smartphones containing a SIM other than the primary SIM tablets laptops and connected watches The devices may connect using any kind of data connection e g mobile data Wi Fi 9 2 User Stories and Feature Requirements US9 1 Asan RCS user I shall be able to connect to and access my RCS messaging services from all of my RCS enabled devices and interfaces R9 1 1 OM There shall be one single primary mobile device for the set of multiple devices belonging to a user The user shall be addressed through the MSISDN associated with that single primary mobile device NOTE The A Party user is not necessarily aware that they are communicating with the B Party s primary or secondary device or interface nor does the functionality offered by the client necessarily have to vary between primary and secondary devices or interfaces US9 2 Asan RCS user with multiple RCS enabled devices and interfaces I shall have available all the RCS messaging features that my service provider offers me on any of my devices or interfaces As an RCS user with multiple devices shall always be able to receive communications on my primary device whenever under either cellular but no data coverage or cellular on data coverage regard
155. ew and now activa RCS instance B 12 a RCS deactived RCS active RCS service entry points greyed out disabled RCS visible and active RCS related user s content available RCS instance switch RCS instance switch visible e g in the according not visible settings section and OFF User enters location of currently deactivated RCS instance switch and switches to ON S Formerly active RCS instance B RCS active RCS in launcher mode RCS visible and active RCS instance not active nor visible i in the device with the exception RCS instance switch of RCS set up icon not visible HTTP request on hold User reactivates RCS in launcher mode instance Figure 2 Status logic flow 2 2 3 User consent Markets may or may not require users to accept Terms amp Conditions T amp C before using RCS To reflect those different cases two scenarios can be applied display of User Message or display of End User Confirmation Request User Message US2 4 As an operator want to be able to provide information and require consent BEFORE my users use the RCS service R2 4 1 Upon operator discretion a popup showing EITHER Terms amp Conditions OR a Welcome Message OR no popup is shown shall be displayed to the user during first time configuration NOTE Display of Terms amp Conditions requires two buttons e g accept amp decline for user action while display of Welcome Messa
156. faces opening and responding to a new incoming event belonging to services listed in R9 3 Page 104 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document NOTE R9 3 14 NOTE R9 3 15 R9 3 16 R9 3 17 NOTE V2 0 R9 3 18 R9 3 19 R9 3 20 4 on one of their devices interfaces shall trigger the clearing of the notifications for that same message on their other RCS enabled devices and interfaces i e if the message is read on one device interface it is marked as read on other devices and interfaces Taking into account the potential concession of R9 3 6 OM The device or interface from which a Chat response to a Chat incoming event is sent becomes the active device interface for that session The Chat response and any further Chat messages in that session will be made available in real time on this active device interface only as long as the session is active Any other device interface not active for that conversation session becomes an inactive device interface for that session OM an RCS user with multiple RCS enabled devices and or interfaces shall perceive the reception of events belonging to services listed in R9 3 4 to be real time on any device or interface with the RCS app open OM Events e g messages content notifications for that conversation session shall be available on inactive devices interfaces for tha
157. figuration parameters Based on the definition of these parameters in RCC 07 this leads to the following valid combinations RCS IP VOICE CALL Behaviour PROVIDE RCS a0 0 107 1 N E BREAK OUT Only cellular voice call service available no voice service when only in Wi Fi coverage for primary devices and no voice service for secondary devices 1 1 Whenever in cellular coverage only the applicable cellular voice call service is available i e no user choice Wi Fi voice service with breakout when in Wi Fi coverage without cellular coverage on primary device Table 29 RCS IP Voice Call configuration parameters combinations R10 13 6 The enabling disabling of the RCS IP Voice Call functionality on a secondary device requirement R10 7 1 shall be realised through the related configuration parameter i e PROVIDE RCS IP VOICE CALL as described in RCC 07 R10 13 7 Multi party call establishment rules are up to the policy of the service provider user story US10 8 and shall be developed as described in section 2 3 3 of PRD IR 92 R10 13 8 For the requirements of US10 9 RCS IP Voice emergency call services are subject to local regulation and service provider policies as per section 2 2 1 of RCC 07 V2 0 Page 117 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document R10 13 9 Regarding Supplementary Services user story US10 10
158. fined way to find out automatically compliancy to the airline policy for enabling Wi Fi is up to the end user Requirement R15 1 7 is fulfilled through the RCS IP voice service as described in IP Voice Call page 113 For requirement R15 2 1 such zero rating is possible for the HPLMN operator for all services because messages and signalling always pass through the home network and target well defined addresses That allows to differentiation from other traffic R15 5 10 For the VPLMN for requirement R15 2 1 zero rating would always be possible for SMS whereas MMS and File Transfer via HTTP use a home routed APN which will prevent the VPLMN from applying such differentiated charging in an easy way allowing only for generic volume based charging without differentiation between signalling and media For the enablers for the other operator messaging services RCS Chat Standalone Messaging and File Transfer via MSRP the situation for the VPLMN operator depends on whether or not IMS roaming is in place for RCS Without IMS roaming or if RCS is not using IMS roaming i e TE2 zero rating will not be possible allowing only for generic volume based charging without differentiation between signalling and media If IMS roaming is in place the VPLMN can differentiate between the signalling to establish the session and the media streams but for the media stream itself only volume based charging can be applied without further differentiation
159. g only As a user want to enable or disable MMS download in roaming case in Integrated Messaging R16 6 1 The user shall have the option to enable or disable the automatic download of MMS whilst they are roaming R16 6 2 The default setting shall be disabled US16 7 As a user want to personalize my device and need access to settings that allow me to do so R16 7 1 The user should have the option to personalize the native or downloadable RCS client The following features should be covered e Notification sounds for incoming RCS events e g One to One Messages Group Messages File Transfers e Notification preferences e Customized ringtones for RCS IP calls or Video over IP V2 0 Page 157 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document e Visual customization for chat for example fonts bubble styles backgrounds etc US16 8 As a user want to enable or disable the sending of the notification that tells the sender the message was displayed R16 8 1 The user shall have the option to enable or disable the sending of a notification to the sender that tells the sender the message was displayed R16 8 2 The default for this setting shall be enabled US16 9 As a user want to enable or disable automatic acceptance for File Transfer R16 9 1 The user shall have the option to enable or disable auto acceptance for incoming File Transfer R16 9
160. ge 84 Requirement R8 1 12 shall be implemented locally on the device As an Audio Message is a file it shall be part of a Chat conversation as required by requirement R8 1 13 The content of the Audio Message can be played directly from the Chat application upon user action This is indicated by the File Disposition being set to render see section 3 11 4 2 2 of RCC 07 e For FTOHTTP the File Disposition is located in the file disposition attribute of the file info element of the main file e For FToMSRP the File Disposition is the File Disposition SDP attribute as described in RFC5547 Requirement R8 1 13 1 sets a limit of ten minutes for a recorded Audio Message This is achieved by setting the MAX RRAM DURATION parameter defined in section A 1 16 of RCC 07 to 600 seconds Page 100 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document 8 3 2 2 Notification on Receiving Audio Messages R8 4 16 As an Audio Message is a file See File Transfer incl Geolocation Push page 84 e Notifications shall be triggered hence requirement R8 2 1 is covered e Sorting as per requirement R8 2 3 is covered e Action resulting to the selection of a visual notification as per requirement R8 2 4 is covered R8 4 17 Requirement R8 2 2 shall be implemented locally on the device 8 3 2 3 Receiving Audio Messages R8 4 18 As an Audio Message is a file e It shall c
161. ge requires only one button e g Ok V2 0 Page 16 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document R2 4 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 za X gt Service Conditions Figure 3 Example Terms amp Conditions pop up R2 4 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 4 4 If the user declines the User Message RCS services shall not be available on the device the RCS client shall become inactive and not visible on the device for details see R2 3 12 and Figure 2 page 16 R2 4 5 In case of decline a retry algorithm shall be able to retrigger the service activation and T amp C acceptance process on RCS capable networks The retry algorithm shall be a retry after one day then after one week then after one month then END End User Confirmation Request US2 5 As an operator want to be able to provide information and require consent from my users AFTER the RCS service has been activated R2 5 1 Upon operator discretion a popup showing a message e g Terms amp Conditions OR a Welcome message shall be displayed to the user a
162. hall offer full function R7 21 2 2Legacy devices non RCS or on a RCS version that does not support Geolocation Push should offer legacy mode function NOTE Any details of Multi Device Support shall be as described in Messaging for Multi Device page 102 US7 22 Asauser want the ability to share my current position or a selected location with any of my contacts RCS contacts or legacy non RCS contacts NOTE Pre requisite The Geolocation Push Service relies on a map function on the sending device that supports the RCS functionalities NOTE Pre requisite There is no intention to build positioning or map functions within the RCS standard R7 22 1 Chat Group Chat and In Call Sharing shall be service entry points to initiate a Geolocation Push R7 22 2 There may be other service entry points available on the device to initiate a Geolocation Push e g Contact Card call log R7 22 3 The Geolocation Push Service should offer a legacy mode to send positions or locations to non RCS recipients or recipients with RCS versions that do not support Geolocation Push NOTE Legacy mode may be provided by a link to an online map display or a screenshot with map picture US7 23 As a user want to pre view an automatically detected position on map and have the ability to change this manually before sending V2 0 Page 91 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service De
163. hanged with a contact ina single threaded view As a user want a single environment for creating and viewing my messages covering a multitude of different services By having this convenience don t have to change apps to carry out similar messaging tasks R4 1 1 In Operator Messaging the user shall see any Messages and File Transfer events exchanged with a single Contact grouped into one Conversation thread V2 0 Page 36 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document R4 1 2 All Messages and File Transfer events shall appear in order of the time that they have been sent and received on the device Details for message order are defined in 1 to 1 Chat page 61 and File Transfer incl Geolocation Push page 84 R4 1 3 The Operator Messaging application shall combine the composing of RCS Messaging and File Transfer with xMS messaging R4 1 4 All Operator Messaging Services shall be offered consistently over primary and secondary devices NOTE Full details are described in Messaging for Multi Device page 102 R4 1 5 Operator Messaging shall have no impact on the RCS Group Chat experience of the user NOTE RCS Group Chat is the only Operator service today that delivers a full group chat experience hence there is no integration necessary R4 1 6 All messaging entry points on a device shall ensure access to the full Operator Messaging experie
164. he live video share US12 8 As a user sharing video i e user A B want to stop sharing video at any point during the call without interrupting the underlying voice call R12 8 1 OM A user shall be able to terminate either its own and or a received video share at any point during the call NOTE This is an explicit stop of the transmission not a hiding of video while the actual stream is continuing US12 9 As users sharing video we want to continue our call as voice call only if video support is lost during the call on either video sharing leg R12 9 1 OM Incase of loss of a video share due to any reason the underlying voice call shall continue US12 10 As users sharing video both one and two way we want the best possible quality of video available to us for the bearer we use R12 10 1 A Video Share taking place on top of a VoLTE call shall benefit from a higher quality of video than is currently on top of a CS call or RCS IP Voice Call NOTE Following requirement R12 2 3 ViLTE IR 94 is used whenever possible Otherwise use Video Share V2 0 Page 127 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document 12 2 2 2 Upgrade to IP Video Call IP Video Call mainly considers the fact that transmission of both voice and video signal happen always over IP so can basically deliver a lip sync experience between voice and video Upgrade to IP Vide
165. he file has been sent is not received and the V2 0 device does not attempt to transfer the file anymore Page 93 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document NOTE R7 26 4 R7 26 5 NOTE V2 0 R7 26 6 R7 26 7 R7 26 8 R7 26 9 The A Party Operator shall ensure that duplication of messages within the Operator Messaging application is avoided within their network control Notifications on delivery status information as defined in 7 3 2 shall be stored and forwarded in the store amp forward server as specified in RCC 07 The requirement R7 4 1 shall be implemented locally on the device When transferring a large image using File Transfer regardless of whether it is HTTP or MSRP based as described in R7 5 1 a client shall check whether it is possible to reduce the size of the image It may use following mechanism for this e The default scale factor F for the image shall be F min 1280 w 1280 h 1 0 The w width and the h height shall be used in pixels for the calculation e If the factor F is 1 the original image shall be transferred e Otherwise the size of the image shall be reduced using following algorithm o Scale both dimensions by the same factor F same for width and height so the aspect ratio is maintained o Compress as JPG with q 75 o Compare the new image size with the original and only offer the possib
166. iation Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document R8 3 9 OM Incoming Audio Messages shall be represented in Chat Conversations in accordance with requirements in the File Transfer section page 84 R8 3 10 Status notifications for incoming Audio Messages shall be supported in accordance with requirements in the File Transfer section page 84 8 3 Technical Information 8 3 1 Overview An Audio Message is a specifically formatted file as per section 3 11 4 1 of RCC 07 that is recorded on the sender s device using the Adaptive Multi Rate AMR codec and exchanged with contacts via the File Transfer feature Audio Message is a File Transfer specific content type as specified in sections 3 5 1 1 2 amp 3 5 4 9 2 of RCC 07 As such Audio Messaging uses the procedure defined for File Transfer as per RCC 07 section 3 5 to exchange Audio Messages such as e Procedures for handling File Transfer interruptions and failures e Use of delivery notifications e Rules for Auto Accept e Use of a local device blacklist e Rules for managing shortage of space for local storage Any contact having the File Transfer capability is seen as being compatible with Audio Messaging An Audio Message is identified via its format section 3 11 4 1 of RCC 07 and shall be displayed accordingly by the UI A specific icon pre embedded in the device shall be associated to the Audio Message The conten
167. ice All of a user s capabilities for their RCS services on all of their RCS enabled devices will be combined into a single set of capabilities which is shared with other users Other users will not be able to determine on exactly which device another user has a specific capability nor will other users know whether the cepavines user has multiple RCS devices available to him at all using this capability information shared The party that initiates a communication event e g creates and sends a chat A Party me message or File Transfer or initiates a call App Smartphone application App ID Unique identifier for an application Auto Accept A function on the device that shortcuts the user manual acceptance of the incoming communication event such as chat files etc The party that receives or is intended to receive a communication event e g e Pay Chat Message or File Transfer from A Party Capability A contact has a device registered for RCS service that can initiate or respond Availability to a requested RCS service Chat Message A single text message that was conveyed from one user to another using the RCS Chat service Common Message Store CMS A network storage that enables Multi Device and Backup and Restore use cases A contact is a communication partner either selected from the device contact Contact list or typed into the dialler as a phone num
168. ice and all features around the core 5 2 User Stories and Feature Requirements US5 1 NOTE V2 0 R5 1 1 As a user want to send Chat Messages to my contacts This document describes the Chat Service functionality for contacts on net or on an Interconnected RCS service Other contacts may have less functionality available Please refer to Operator Messaging page 36 OM Any RCS user shall be able to send a Chat Message to Contacts in the contact list Page 61 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document R5 1 2 The user shall have the option to send a message at any time by entering an existing chat and continuing NOTE The 1 to 1 chat has no visible end Despite the way it is technically realised to the user it will always appear as a thread of messages to which they can reply at any time The user may switch to other screens any time during or after a chat without affecting the chat history or the option to resume the chat at a later time US5 2 As a user I want to see the status of my sent Chat Messages R5 2 1 OM For A Party the following message states shall be supported R5 2 1 1 Message Pending Transfer of the Chat Message in progress e g queuing on device R5 2 1 2 Message Sent confirmation that the message has been correctly accepted by the A Party s network R5 2 1 3 Message Delivered Confirmation that the message has
169. ice entry point colour will change and the In call service entry point will become unselectable 1 The In call service entry point will be conditionally visible and always selectable In the case when In call service capability exchange is successful the service entry point is visible and selectable In the case when In call service capability exchange fails the service entry point will change and remain selectable NOTE The INCALL UX is only valid for RCS users and non RCS users that have discoverable video capability NOTE Successful capability exchange includes the incall service capability Table 5 In Call Service Entry Point Ux Configuration Parameter V2 0 Page 32 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document L N lt X gt ae UX videoUX woo oo o oo Ng A incallUX Saya es Figure 4 UX MO sub tree The associated HTTP configuration XML structure is presented in the table below lt characteristic type UX gt lt parm name videoUX value X gt lt parm name incallUX value X gt lt characteristic type Ext gt lt characteristic gt Table 6 UX sub tree associated HTTP configuration XML structure Node lt x gt UX Under this interior node Common Core related parameters are placed being used to control the UX of the client Sta
170. ide the user a seamless experience when transferring images and be aligned with other internet applications providing the service there is a proposal for a compression mechanism for images which are transmitted using the Image Share service and is similar to the mechanism for File Transfer described in section 7 4 3 2 of RCC 60 The recommended approach based on the principle of maximizing the range of devices resolutions where the image will be displayed with sufficient quality is the following The default scale factor F for the image shall be F min 1280 w 1280 h 1 0 It shall be noted the w width and the h height shall be used in pixels for the calculation Please note that if the factor F is 1 the next step can be skipped Scale both dimensions by the same factor F same for width and height so the aspect ratio is maintained Compress as JPG with q 75 Compare the new image size with the original and only offer the possibility to send a resized image if the resulting file is smaller than the original one When a user sends an image to another user the size reduction algorithm will take place Then if o the scale factor F of the algorithm is lower than 1 and o the result of the compression is a smaller file The smaller file will be used for the Image Share service Otherwise the original file will be used Note that any process to evaluate and execute the size reduction shall occur prior to the image share ser
171. ient Manifest meta data properties R2 11 6 2Android RCS clients shall define a settings screen activity that can be open by third party applications by using a simple intent which action string is equal to the value of the gsma joyn settings activity meta data property Sending that intent to open the settings screen shall require no permission Thus the user decides or not to deactivate the third party application R2 11 6 3The following example illustrates the meta data that shall be added to the Manifest xml file as well as a sample settings screen activity 1 The naming of the parameters includes joyn for historic reasons to ensure compatibility with legacy joyn clients implementing the same mechanism for similar purposes It is required to be provided regardless of whether the client implements a joyn profile V2 0 Page 21 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document lt application android icon drawable icon android label string app_name gt lt the following meta data is used to identify the application as an RCS client gt lt meta data android name gsma joyn client android value true gt lt the following meta data is used to provide the value of the intent action that can be used by other applications to start the RCS client settings screen gt lt meta data android name gsma joyn settings activity android
172. ient logic shall propose the Messaging Service either xMS based or RCS based to be used for that message The device UI shall indicate to the user before a message file is sent what the currently selected Messaging File Transfer Service is The user shall have before the Message Composing or File Selection process the opportunity to change the Messaging or File Transfer Service and select from supported services and overwrite the proposed setting This shall be a one click experience on UI level The user should have at any time during the Message Composing or File Selection process the opportunity to change the Messaging or File Transfer Service and overwrite the proposed setting This shall be a one click experience on UI level A warning may be shown to the user when the composer changes the sending Messaging Service whilst the user is typing a message informing them that xMS or chat services are charged as per their tariff The user shall have the possibility to dismiss such a notice permanently A manual user selection of a Messaging or File Transfer Service during an active conversation shall be persistent until either manually changed again by the user or until the user navigates out of the conversation thread A new conversation will trigger automatic selection of the proposed service when it s being created The creation of new conversation shall trigger the automatic selection of the proposed Messaging Se
173. ieved by reading its Manifest meta data property named gsma joyn settings activity After disabling the active client its settings screen shall be closed and the new client shall be given control again The new client shall then perform these first time start checks again which would lead to the conclusion that there is no active client and that therefore the new client shall become the active client see NOTE If there is no existing RCS client or that none of them are enabled the new RCS client may proceed with provisioning and registration Once the client is successfully provisioned and registered to the network it shall open its own pckgname gsma joyn preferences shared preferences and set its own gsma joyn enablea property to True NOTE As required in requirement R2 3 5 this will be done automatically for a client V2 0 that directed the user to the settings screen of the currently active client when that active client is disabled as a result R2 11 7 2 f the RCS client is disabled e g user switch in settings set to OFF it shall open its own pckgname gsma joyn preferences shared preferences and set its own gsma joyn enablea property to False R2 11 7 3This start up behaviour shall also apply when there is an attempt to re activate the disabled client and when the disabled client is re started R2 11 8 When an active RCS client is disabled a HTTP configuration request with the vers parameter set to 1 as describ
174. ility to send a resized image if the resulting file is smaller than the original one The requirement of user story US7 5 shall be implemented locally on the device The file size limits required in the user story US7 6 are configured via the FT MAX SIZE FT WARN SIZE and optionally FT MAX SIZE INCOMING parameters defined in section A 1 5 of RCC 07 The technical implementation of the requirements of user story US7 7 is defined in section 3 5 4 2 and 3 5 4 8 3 of RCC 07 The technical implementation of the cancellation of the File Transfer via MSRP as required in user story US7 8 is defined in section 3 5 4 3 of RCC 07 A File Transfer via HTTP shall be cancelled by interruption of the ongoing HTTP transfer flow at the time of user input R7 26 10 The technical implementation of File Transfer store and forward of user story US7 9 is defined in sections 3 5 4 7 and 3 5 4 8 of RCC 07 The file will remain stored for a period determined based on service provider policy fulfilling the requirement in R7 10 1 R7 26 11 The requirement of user story US7 10 is provided by a service provider policy on the messaging server or the HTTP content server R7 26 12 The requirements of user stories US7 11 and US7 12 shall be implemented locally on the device Page 94 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document R7 26 13The client s File Transfer auto accept behaviour d
175. ion US7 19 As auser want my operator to store my sent and received files safely and securely R7 19 1 Any successfully sent and received files shall be stored on the network NOTE This is Common Message Store feature R7 19 2 Details of the network storage shall be controlled by the individual operator including but not limited to R7 19 2 1Total Volume of storage capacity per user V2 0 Page 90 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document R7 19 2 2Maximum storage time of conversations messages files etc US7 20 As a user I want to restore my sent and received files from the network operator storage NOTE Central File Storage e g in case of handset replacement R7 20 1 The user shall have the option to restore transferred files from the network storage e g in case of handset replacement US7 21 As a user want my device to always be in sync with the stored files on the network even in case of multiple devices NOTE Details on synchronization and secondary device use will be described in Messaging for Multi Device page 102 R7 21 1 All user devices shall always maintain full synchronisation of sent and received files NOTE Details on synchronization and secondary device use will be described in Messaging for Multi Device page 102 R7 21 2 In the multi device case R7 21 2 1 All Geolocation Push capable devices of the user s
176. ion R6 3 1 R6 3 2 R6 3 3 R6 3 4 OM Participants in an Open Group Chat Conversation shall be able to add new participants from their contact list OM It shall not be possible to add new Group Chat participants in an Open Group Chat Conversation once the maximum number of participants has been reached as configured by the network operator OM It shall possible to add participants to a Group Chat if they are not registered to the RCS platform offline at the time where the addition takes place OM Other Group Chat participants shall see the new participant irrespective of whether the new participant is registered to the RCS platform online or not offline from the time the new participant was invited US6 4 As a user don t want anybody to be able to add a participant to a Closed Group Chat Conversation after it has been created R6 4 1 OM Participants in a Closed Group Chat Conversation including the creator shall not be able to add any further participants to the Group Chat Conversation once the Group Chat Conversation invites have been sent US6 5 As a user want to know who is participating in a Group Chat Conversation at any point in time As a user want the contact names of Group Chat Participants to be aligned with the according contact card i e if a Contact am in a Group Chat Conversation with is in my contact list the identifying MSISDN shall be replaced with the name from the
177. iple Chat and Group Chat Conversations in parallel R6 24 1 The device shall offer the option of multiple parallel Chat and Group conversations at any given point in time US6 25 As a user want to easily and quickly switch between parallel Chat Conversations NOTE These Chat Conversations may be One to One or Group Chat Conversations R6 25 1 The device shall offer the option to switch between parallel Chat and Group Chat conversations easily and quickly US6 26 As a user want to be able to leave a Group Chat Conversation at any point in time After left a Group Chat Conversation the conversation thread is still visible in the list of my conversations but am neither able to send any messages to that Group nor do receive any kind of updates from that Group NOTE Re joining Group Chat Conversation once left is only possible if the user is re invited to that Open Group Chat Re joining a closed Group Chat Conversation is not possible R6 26 1 OM Any participant in a Group Chat Conversation shall be able to leave that Group Chat at any point in time R6 26 2 OM Any participant who has left a Group Chat Conversation shall no longer receive any new messages or updates to the participants list R6 26 3 After a Group Chat participant has left the Group Chat Conversation shall still be visible in the list of Conversations if not manually deleted containing any messages or participant list updates for the period of partici
178. is one of these features hence requirement R8 1 3 is covered e Interruptions in transfer of Audio Messages hence requirement R8 1 6 is covered Requirement R8 1 4 shall be implemented locally on the device To stay within limits of the File Transfer maximum size as required in R8 1 5 the service provider shall configure the MAX RRAM DURATION parameter defined in section A 1 16 of RCC 07 to an adequate value i e a file encoded with the highest encoding quality for the maximum duration gives a lower resulting file size in Kilobyte than the FT MAX SIZE parameter value Sending Audio Messages Requirement R8 1 7 and its sub requirements are UI related and shall be implemented locally on the device To fulfil requirement R8 1 8 Audio Messaging uses the procedure defined for File Transfer as per File Transfer incl Geolocation Push page 84 section 2 7 to exchange Audio Messages to a group of contacts Requirement R8 1 9 shall be implemented locally on the device Requirement R8 1 10 and its sub requirements are covered via the File Transfer corresponding requirements see File Transfer incl Geolocation Push page 84 Notifications on delivery status information as defined in R8 1 10 7 shall be stored and forwarded in the store amp forward server as specified in section 3 3 4 1 5 RCC 07 Requirement R8 1 11 is covered by the ability to cancel a File Transfer see File Transfer incl Geolocation Push pa
179. ithin the Operator Messaging application is avoided within their network control V2 0 Page 37 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document US4 4 As a user want to ensure that my messages reach their destination as reliably and quickly as possible R4 4 1 R4 4 2 NOTE R4 4 3 R4 4 4 NOTE R4 4 5 R4 4 6 R4 4 7 R4 4 8 NOTE R4 4 9 NOTE R4 4 10 NOTE To avoid a cluttered experience between Operator Messaging users and non Integrated non Seamless Messaging RCS users the user equipment shall be aware of the Integrated Seamless Messaging capability of any of the RCS enabled contacts in order to adjust behaviour accordingly The network operator shall ensure all messages and related messaging services originating from a device shall be conveyed in a manner that will ensure the quickest delivery to the recipient This may involve the network conveying the message or file on a different Messaging Service or File Transfer service OM Store and Forward shall be available and provided by every RCS service provider to host messages and file notifications for its RCS users on the terminating leg when these users are offline For xMS messages sent from the device Store and Forward function shall be available and provided by the operator network Details outside of this RCS specification For MMS files sent from the device the
180. its Feature Tag from where the com has been generated the B party receives the RCS communication in his native RCS app The B Party can reply to A from his native UI and the A party receives it on app and continues the conversation thread A B App RCS UX Trigger IM FT 6 Reply Figure 16 App RCS communication R13 8 3 The RCS APIs available are e Instant Messaging e File Transfer including geo location e Audio Messaging e IP Video Call e Video share during a call e Request for services configuration information relevant for the application e g max number of participants in a Group Chat max file V2 0 Page 139 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document size of a File Transfer warning threshold for a File Transfer IM CAP ALWAYS ON FT HTTP CAP ALWAYS ON US13 9 As a user want to be able to see via capability discovery which of my contacts have installed the same RCS enabled apps as have installed Apps installed on my contacts secondary devices are also discovered US13 10 As a user when I install an RCS enabled app want to be able to decide whether or not want to make it discoverable to other users via capability discovery If opt not to make the app discoverable my contacts will not see that I have installed the app cannot tailor the capability discovery response by contact US13 11 As a user want
181. ity information should be made visible to the user under a general RCS service category via an icon label button This is done to avoid user confusion when similar RCS capabilities use different underlying services for service delivery US3 2 As a user do not want to be disappointed by selecting a communication option that appears to be available but is not R3 2 1 R3 2 2 R3 2 3 RCS service entry points which represent an available service at a given point in time shall be selectable Selecting an available RCS service shall initiate the device dialogue for that service In the case when the recipient B Party has multiple devices RCS service entry points which represent an available service at a given point in time on the A Party device shall be selectable if at least one of the recipient s devices is capable for this service US3 3 As a user want to be sure that the information I have about my contacts RCS service capabilities is up to date and if they are available to communicate using those capabilities R3 3 1 R3 3 2 R3 3 3 Based on a capability discovery or service availability poll performed by the device the user shall be able to see which contacts are equipped and provisioned for certain RCS services Any capability discovery or service availability check of contact s shall happen in the background without the user being aware of this activity Operators can configure how service entry points shall be
182. ize the user interaction for security solutions a case by case analyses of user interaction flows for device configuration and personalization is done below User interactions can be characterized with regard to their user experience as in band or out of band In band refers to user interactions that can be smoothly integrated in the user interface based on well defined RCS signalling flows Out of band refers to user interaction flows that come not with RCS signalling flows but with another media channel most likely a user readable short message R14 4 6 1 HTTP s based client configuration mechanism over 3GPP access as defined in section 2 2 of is transparent for the user if the service provider supports with the network to supports network based user identification If the network operator does not support network based user authentication then it may invoke the procedures for the client configuration over non 3GPP access The corresponding user interactions apply as defined below R14 4 6 2 HTTP s based client configuration mechanism over non 3GPP access as defined in section 2 30f requires user prompt for MSISDN and OTP password which is in band The OTP password in itself is received in between the two prompts is out of band The exact flow depends of the device capabilities to determine the user identity IMSI of the SIM or to receive short messages on UDH ports or the service provider policy to enforce us
183. l has ended the user can return to the Conversation V2 0 Page 67 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document R5 24 4 The user shall be able to receive a video call when actively engaged in a Chat or Group Chat Conversation and return to the chat when the video call ends US5 25 As a user want to block specific users so that do not receive any kind of Chat Message from them anymore R5 25 1 If the sender of a Chat Message is on my local device blacklist the incoming message shall be ignored R5 25 2 Messages from blocked contacts shall neither trigger visual nor audio notification R5 25 3 For messages from blocked contacts Conversations shall not be created R5 25 4 Incoming Messages from blocked contacts shall not be displayed R5 25 5 The recipient has no option to see or respond to messages from a blocked contact 5 3 Technical Information 5 3 1 Overview The 1 to 1 Chat service is provided as defined in sections 2 7 1 1 and 3 3 of RCC 07 For the purpose of the following technical implementation of the user stories and service requirements the 1 to 1 Chat service is considered as a stand alone end to end service The technical implementation of the 1 to 1 Chat service in relation to the integrated messaging experience is provided in Operator Messaging page 36 RCC 07 allows service providers to implement the one to one user experience b
184. l mean that the RCS client is disabled user switch in settings set to OFF or the RCS client has never been provisioned yet R2 11 6 8The RCS client will modify the value of these properties according to the rules defined in the following section R2 11 7 Client start up behaviour R2 11 7 1An RCS client which is started for the first time on a device shall e Retrieve the list of installed applications from the Package Manager and identify existing RCS clients by looking for the Boolean meta data property named gsma joyn client as defined in the previous section V2 0 Page 22 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document For every RCS client that is found the client shall open their shared preferences named pckgname gsma joyn preferences and retrieve the Boolean property gsma joyn enablea as defined in the previous section If an existing RCS client is found with the Boolean property gsma joyn enablea set to True it means that client is already active on the device The new client shall inform to the user that there is another RCS client already configured in the device and that as a pre requisite to use this one it is necessary to disable it In the same pop up the possibility to access the RCS settings of the active RCS application via intent mechanism shall be offered The intent action used to open the active RCS client settings screen shall be retr
185. lds are considered key fields No data of these fields should be lost when contact information is exchanged by any means peer to peer contact sent uploaded synchronized etc e Name e Telephone numbers e Email addresses e Address information e Personal information e The Minimum subtypes that should be supported are defined in the PCC definition in CAB_TS e Name Composed names such as Jean Baptiste shall be supported properly e Personal Information Nickname Photo Birthdate Comment Oo O00 0 e Telephone number At least the following subtypes of telephone number shall be supported Land home Land work Land other Mobile home Mobile work Mobile other Fax work Fax other Beeper Other O O OnO COO V0 OnO LO e Email addresses The following subtypes shall be supported Email work 1 Email work 2 Email home 1 Email home 2 Ov OOO Page 162 of 166 GSM Association Non confidential RCS Common Core 1 1 Service Description Document o Other e Address information o Address o Geographic Position o Timezone Sending and receiving a contact card via File Transfer is technically the same as sending any other file If the format for pushing a contact card file is vCard 2 1 or 3 0 formats the MIME Multipurpose Internet Mail Extensions type that shall be used for the File Transfer is text vcard If the format for pushing the contact card is CAB Converged Address Book 1 0 PCC XML form
186. lemented via the Geolocation PUSH feature defined in section 3 10 of RCC 07 8 Audio Messaging 8 1 Description The Audio Messaging feature allows RCS users to send Audio Messages to one or more RCS users at a time Audio Messaging provides a new dimension of communication using the spoken voice to convey a message allowing the recipient to listen to the message within their RCS interface The handling of Audio Messaging files follows the rules of File Transfer as described in File Transfer incl Geolocation Push page 84 with the following refinements detailed below 8 2 User Stories and Feature Requirements US8 1 As a user want to record and send an Audio Message to one or more of my RCS contacts at a time R8 1 1 OM An RCS user with the Audio Messaging feature will be able to see which of their contacts can receive Audio Message files V2 0 Page 95 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document NOTE R8 1 2 R8 1 3 R8 1 4 R8 1 5 R8 1 6 This is not based on a specific Audio Messaging capability but the ability of the user to support RCS File Transfer as per Capability Discovery and Service Availability page 25 It shall be possible to create and send an Audio Message in Chat and Group Chat conversations Audio Messaging shall use File Transfer Store amp Forward as defined in the File Transfer section page 84 OM Audio M
187. less of the connectivity state of the secondary device s and interface s R9 2 1 OM an RCS user with multiple RCS enabled devices and interfaces shall be able to perform all of the following actions on all of these devices and interfaces V2 0 Page 102 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document R9 2 2 NOTE R9 2 3 R9 2 4 R9 2 5 R9 2 6 NOTE US9 3 Receive any of the services and any pertaining notifications listed in R9 3 4 Notifications for events belonging to a session which is already active will not be displayed on inactive devices interfaces for that session nor on the active device interface for that session if the user has the conversation window open and visible as per requirements Error Reference source not found and Error Reference source not found Create and send any of the services listed in R9 3 4 Forward delete and resend any of the services listed in R9 3 4 Reply to any of the services listed in R9 3 4 The primary mobile device shall also be able to perform the above actions R9 2 2 and R9 2 5 when connected to mobile cellular network only i e when not connected to mobile data or Wi Fi In this case it is acceptable that functional limitations of the services apply e g SMS limitations apply to text messages Requirement R9 2 6 is OM for operators using the Integrated Messaging configuration of IM CAP ALWAYS ON
188. ll allow the user to select the default sending method to be used when the user sends a message The user is able to select e Proposed Messaging Service follow Integrated Messaging behaviour as defined in Integrated Messaging requirements or e SMS or e RCS chat The default setting shall be Proposed Messaging Service Page 41 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document R4 10 3 It shall always be visible to the user which Messaging Service is used and the user shall have the option to change the chosed Messaging Service irrespective of the setting in R4 10 1 upon user interaction as a case by case decision taken in the messaging composer 4 2 1 2 Variant 2 Seamless Messaging User Stories Requirements US4 11 As a user want to send a message without knowing about the underlying technology service that is being used to convey my messages file shares want the operator to deliver the message the best possible way to the intended recipient s As a user don t want my Messaging Application to show the Messaging Service being used when messages are displayed in my inbox R4 11 1 The RCS client can be configured to automatically send RCS messages when connected and registered for the RCS service NOTE If the client is not registered for RCS service it will follow the seamless messaging service logic defined in secti
189. ll is not possible for a device that only has Wi Fi coverage R15 5 3 For requirement R15 1 2 such zero rating is possible for the Home Public Landline Mobile Network HPLMN operator as well as for the Visited Public Landline Mobile Network VPLMN operator for the voice service itself For the configuration of supplementary service by a VoLTE subscriber the HPLMN operator can zero rate based on the specific destination of the traffic Given that a home routed APN is used for XCAP such differentiation of traffic may not be possible for the VPLMN operator V2 0 Page 153 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document NOTE V2 0 R15 5 4 R15 5 5 R15 5 6 R15 5 7 R15 5 8 R15 5 9 Rating in the VPLMN is only relevant for inter operator charging and thus not directly for the end user The inter operator charging model should be such though that the end user model makes sense from business perspective For requirement R15 1 3 see R15 5 2 Requirement R15 1 4 shall be implemented locally on the device taking into account the behaviour of RCS services in relation to the current data off setting configured as per R15 5 21 For requirement R15 1 5 see R15 5 3 Requirement R15 1 6 shall be implemented locally on the device when the operator has configured RCS IP Voice to be available over Wi Fi see IP Voice Call page 113 Since the device has no de
190. llowing R3 3 7 1 R3 3 7 2 R3 3 7 3 R3 3 7 4 R3 3 7 5 The operator shall be able to define a minimum time span between two full contact list scans this includes the option to select no subsequent full contact list scans Polling of RCS enabled contact s shall only occur when the RCS capability information for the contact is older than the operator configured value The device shall only perform capability scans of the entire contact list when connected to a charger The device may split very long contact lists into chunks and perform the regular contact list updates on subsequent charging cycles A new scan of the contact list or set of contacts shall not commence until the previous one was completed The device shall request a RCS capability discovery and or service availability check update of an individual contact when the capability information is invalid or expired AND one of the following applies R3 3 7 5 1 When a new contact is added to the address book If this contact is RCS enabled their current RCS capabilities shall be displayed R3 3 7 5 2 When opening that contact from the contact list R3 3 7 5 3 When starting a conversation with that contact e g when adding a contact to the To field of a new message R3 3 7 5 4 When opening a conversation or thread with that contact R3 3 7 5 5 When the capability information expires or when an operator configurable timer expires for a
191. lti media content in my Chat Conversations e g but not limited to take an instant picture from camera and send from within the chat NOTE Details on multi media content are covered in File Transfer incl Geolocation Push page 84 R5 16 1 The user shall be able to select and send Multi Media in Chat Conversations NOTE Details on multi media content share are covered in File Transfer incl Geolocation Push page 84 R5 16 2 OM The user shall be able to receive Multi Media in Chat Conversations NOTE Details on multi media content share are covered in File Transfer incl Geolocation Push page 84 US5 17 As a user want to maintain multiple Conversations in parallel NOTE These Conversations may be one to one or Group Chat Conversations R5 17 1 The device shall offer the option of multiple parallel Chat and Group Chat Conversations at any given point in time US5 18 As a user I want to easily and quickly switch between multiple parallel Conversations NOTE These Conversations may be One to One or Group Chat Conversations R5 18 1 The device shall offer the option to switch between Conversations easily and quickly US5 19 As a user want my messages backed up on Common Message Store which is trusted and safe R5 19 1 OM All Conversations shall be stored on the network NOTE Details of that storage are at the individual operator discretion R5 19 2 The operator shall be able to determine the
192. ltimedia Messaging Service MMS 1 6 Differences to previous versions RCS Common Core 1 1 is a maintenance update that provides further clarification to existing requirements The technical information has also been updated to align with RCS 5 3 see section 1 5 of RCC 07 1 6 1 Summary of Changes e Device Provisioning o Alignment with RCC 14 and RCC 15 e Capability Discovery and Service Availability o Clarification on the behaviour of the CAPABILITY VALIDITY timer see requirement R3 3 7 5 6 e Operator Messaging o Clarification to the Integrated Messaging requirements for proposed message selection see section 4 2 1 1 o Clarification on the DELIVERY TIMEOUT behaviour and technology selection logic for Integrated Messaging variant 1 see section 4 2 3 e One to One Chat V2 0 Page 10 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document o Additional requirements for handling unseen messages and files see requirements for user story US5 13 e Group Chat o Additional requirement introduced to allow the user to see who set up the Group Chat see requirement R6 6 2 e IP Voice Call o Additional user story included to allow the user to see what the call bearer is in use for the call see requirements for user story US10 12 e Introduction of LED notifications for received one to one group chat and file transfer messages e Editorial clarifications to Audi
193. ly compatible e Capability discovery If the result of the exchange is that VILTE is supported in one end and RCS IP Video Call is supported in the other the IP video call shall be available to both ends e Service initiation and acceptance A ViLTE only device shall accept an incoming SIP INVITE for RCS IP Video Call as a SIP INVITE for ViILTE and vice versa as the services are compatible o An overview of the availability of the two Technical Enablers based on various factors e g coverage APN used etc for originating and terminating side can be found in section 3 9 4 of RCC 07 For the cases where both Technical Enablers are available on the originating side the Technical Enabler that applies is based on configuration parameter IP Video DEFAULT MECH defined in RCC 07 11 3 2 Technical Implementation of User Stories and Service Requirements R11 18 1 The realisation for requirement US11 1 including is covered in section 11 3 1 R11 18 2 Requirement R11 1 1 shall be implemented locally in the device R11 18 3 Regarding requirement R11 1 2 the implementation is restricted to the RCS IP video call enabler TE2 see section 11 3 1 R11 18 4The requirements for user story US11 2 including R11 2 1 and R11 2 2 are fulfilled via the required capability exchange as highlighted in section 11 3 1 NOTE to allow service providers to guarantee that access to the ViLTE service is available with non RCS users with ViLTE capable devices an a
194. mentation of the Closed Group Chat is defined in section 3 4 4 2 of RCC 07 R6 37 2 The subject of a Group Chat Conversation as defined in user story US6 2 is implemented in accordance with sections 3 4 4 1 1 and 3 4 4 1 2 of RCC 07 R6 37 3 The client shall allow members of an Open Group Chat Conversation to add new participants as defined in section 3 4 4 1 2 of RCC 07 to fulfil the requirements of user story US6 3 NOTE To avoid sending notifications to participants twice in short succession the conference focus shall briefly delay notifying the existing participants of the pending state of the newly added participant to allow for automatic acceptance of the Chat e g because of Store and Forward In that case the participant s state will change to active almost immediately V2 0 Page 81 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document V2 0 R6 37 4 The technical implementation of the clients and the messaging server to provide the Closed Group Chat as defined for user story US6 4 shall be based on section 3 4 4 2 of RCC 07 R6 37 5 In order to be able to display the list and status of users in a group conversation as required in user story US6 5 each client shall subscribe to the conference event package as defined in section 3 4 4 1 1 of RCC 07 The client will be informed by the Messaging Server about the list of participants and their statu
195. messages R5 12 1 OM The date and time associated with each chat message shall be displayed adjusted to the current device date and time R5 12 1 1This timestamp shall be generated for sent messages by the device ina consistent way as timestamps are generated for other device functions e g SMS R5 12 1 2Timestamps for received messages shall be based on the UTC timestamp that comes with each message aligned with the selected device time zone US5 13 As a user want conversations which contain unread messages to be differentiated from conversations that contain messages have seen NOTE 1 This requirement shall be valid for Messaging for Multi Device as well NOTE 2 Unseen files or file download notifications cover events that use File Transfer as an enabler e g but not limited to Geolocation Push Audio Messaging or vCard share R5 13 1 Conversations with unread messages or unseen files or file download notifications shall be marked accordingly e g by display of subject line in bold font and or an unread message counter R5 13 2 Conversations shall on reception of a new message elevate to the top of the Chat or Group Chat Conversation list R5 13 3 lf the device supports a notification LED for screen off notification then this LED shall flash as long as there are unread RCS messages The colour should differentiate from notifications of other applications but may be identical for all Operator Messaging services U
196. n Core 1 1 Service Description Document Figure 7 Technology Selection Logic During an ongoing Conversation when current composer is xMS IM_CAP_ALWAYS_ON 0 4 2 3 3 During an on going RCS conversation R4 13 1 5During an on going RCS conversation the proposed Messaging Service shall change according to Figure 9 including but not limited to the following cases R4 13 1 6When an xMS message is received from the B party This will cause the DELIVERY TIMEOUT timer to expire R4 13 1 7When the B Party is an Integrated or Seamless Messaging user and expiry of the Delivery Timeout timer occurs There is no immediate change to the Messaging Service if the A Party loses data connectivity the device waits for the expiry of Delivery Timeout before changing to xMS NOTE Note No Cap check performed Ongoing conversation means Causes Delivery timeout to expire either Initial Cap Check Valid Complete OR messages have been sent or received whichever happens first L2 Does B party have L3 Is there a YES gt Chat Delivery Timeout Chat Composer Open in Ongoing Conversation 2 Switch to xMS NO No change to composer Figure 8 Technology Selection Logic During an Ongoing Conversation when current composer is Chat IM_CAP_ALWAYS_ON 0 For details of the technology selection logic if the end user manually changes the flow Manual service change 4
197. n disappears already after selecting the notification and seeing the list of Chat or Group Chat conversations Any audible or visual notification shall be suppressed in case the reception is visible on the currently active screen of the device E g if the user is currently on the Chat screen with a person and a Chat Message is received US5 11 As a user want to view my sent and received Chat Messages in a time based order R5 11 1 OM All messages exchanged 1 to 1 with the same contact shall be threaded in the same chat thread NOTE Where a contact has multiple phone numbers then a thread should be created for each phone number The thread name should clearly show which identity is in use e g work home and so on R5 11 2 OM The order of messages shall be in line with the order messages have been sent and received on the device R5 11 3 OM The originating network shall have the ability to recall RCS messages from the terminating store NOTE This requirement does not affect any messages which have already been delivered to the terminating device R5 11 4 Incoming and outgoing messages shall be displayed interlaced R5 11 5 Sent messages shall be inserted into the Conversation thread as they have been created V2 0 Page 64 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document US5 12 As a user want to see the timestamp associated with each of my sent and received
198. n on message management R4 5 7 The Operator Messaging application must conform to the Messaging Service requirements when sending xMS messages from the device Variant a Operator Messaging as default Variant b OTT messaging app as default Native RCS app Native RCS app RCS xMS OTT RCS Message Message Message Message type Figure 5 Integration of Operator Messaging into native and OTT applications V2 0 Page 39 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document 4 2 1 Operator customization variants for representation of Operator Messaging variants on the device 4 2 1 1 Variant 1 Integrated Messaging User Stories Requirements US4 6 As a user I want a service logic to propose the Messaging Service to be used US4 7 As a user want to be able to override the proposed Messaging Service during the message composing and file selection processes US4 8 As a user always want to know what type of message am sending before submitting it and want this information to be clearly represented on my screen US4 9 As a user always want to know the type of message or file have sent and want this information to be clearly represented on my screen R4 9 1 R4 9 2 R4 9 3 NOTE R4 9 4 NOTE R4 9 5 R4 9 6 R4 9 7 R4 9 8 R4 9 9 V2 0 When opening the conversation or entering the message composer on the device the cl
199. nce NOTE For native implementations US4 2 As a user want to know the status of any messages or files have sent R4 2 1 States for sent RCS messages and files as described in 1 to 1 Chat page 61 Group Chat page 71 and File Transfer incl Geolocation Push page 84 shall be supported in Operator Messaging R4 2 2 For legacy xMS messages sent from a device Delivery Notifications may be supported upon user choice or network default configuration R4 2 3 For legacy xMS messages sent from a device Display Notifications will not be available R4 2 4 For legacy xMS messages sent from a device the message status pending Shall be provided e g for messages queuing on the device R4 2 5 For legacy xMS messages sent from a device the status Message failed shall be supported in case the message could for whatever reason not be sent re sending the message may be triggered manually by the user US4 3 As a user want to ensure that my messages are received in a user friendly way R4 3 1 The A Party Operator shall be able to request to revoke a message that has been sent to the B Party e g but not limited to the case that a Delivery notification has not been received and the operator intends to try a second delivery using a different Messaging Service NOTE The Operator of the B Party may not be able to revoke a message R4 3 2 The A Party Operator shall ensure that duplication of messages w
200. nce with the requirements for user story US16 8 then a client receiving a message or file shall disregard the disposition notification header with value display and not generate a notification for displayed R16 16 9 The configuration parameters for automatic acceptance of File Transfer shall be implemented locally on the device The parameters shall overwrite the service provider auto acceptance settings provided by the FT AUT ACCEPT defined in section A 1 5 of RCC 07 The FT AUT ACCEPT value received in the client configuration provides the default settings of the FT Auto Accept parameter controlled by the user Once the user has altered the settings the value of FT AUT ACCEPT from the device configuration becomes irrelevant R16 16 10 The requirements for user stories US16 10 to US16 15 shall be V2 0 implemented locally on the device Page 161 of 166 GSM Association Non confidential RCS Common Core 1 1 Service Description Document Annex A Supporting requirements A 1 Personal Card format Current implementations of the vCard standard by different device manufacturers leads today to data loss of certain contact information when this information is exchanged among devices or synced with network address books An RCS compliant device shall support receiving ata minimum vCard 2 1 vCard21 and vCard 3 0 formats RFC2425 RFC2426 and may support also the Personal Contact Card PCC format CAB_TS The following fie
201. nd non RCS contacts R3 3 3 4 2 Variant B The IP Video Call service entry point shall be visible and selectable by the user if there is a high likelihood that the IP Video Call attempt will be successful at that time If this attempt is unlikely to be successful the appearance of the IP Video Call service entry point shall change and remain visible and selectable for any phone number including RCS and non RCS contacts R3 3 3 5 For In Call Services the operator shall have the option to configure the device behavior on a per device basis in one of the following ways R3 3 3 5 1 Variant A The In Call Service service entry point s shall be visible and selectable by the user if there is a high likelihood the respective In Call Service attempt will be successful at that time If this attempt is unlikely to be successful the service entry point for In Call Services shall be greyed out and not selectable R3 3 3 5 2 Variant B The In Call Service service entry point s shall be visible and selectable by the user if there is a high likelihood the respective In Call Service attempt will be successful at that time If this attempt is unlikely to besuccessful the appearance for the service entry point s for the In Call Service shall change and remain visible and selectable NOTE 1 Where service entry points are shown on key touch points shall be up to each individual operator operator interest groups or OEMs client developers NOTE 2
202. nd the B party is Offline Some devices however allow users to enter both text and files while composing a single message R4 16 4 When a single message includes both text and file components the entire multimedia message must be conveyed using the same messaging service to preserve the consistency of the message R4 16 4 1The MMS service must be used if xMS has been selected by the client logic for either the text and or the file components of the multimedia message R4 16 4 2RCS chat and RCS File Transfer must be used only when RCS has been selected by the client logic for both the text and the file components of the multimedia message 4 3 Technical Information 4 3 1 Overview Operator Messaging is a client functionality to provide the user with a common messaging service behaviour using multiple services and technologies The sections US4 6 through US4 16 provide the functional requirements for the client to select and apply the specified service behaviour for a number of messaging services Whilst the Operator Messaging Service User Stories and Feature Requirements deal with the co existence of the services in the client there are service definition documents that define the service behaviour of the single services For some services the desired service requirements may be provided by multiple technologies The following service implementations are involved e The RCS 1 to 1 Chat service refers to the service defined in
203. ng a visual notification shall trigger the appropriate action according to requirements in the File Transfer section page 84 V2 0 Page 97 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document 8 2 3 Receiving Audio Messages R8 2 5 R8 2 6 R8 2 7 R8 2 8 R8 2 9 R8 2 10 OM For Audio Messaging the rules of File Transfer Auto Accept shall be in line with the according requirements in the File Transfer section page 84 A user will be notified of Audio Messages sent to them whilst they were offline as soon as they become online again Incoming Audio Messages from Contacts on the local device blacklist shall follow requirement R7 17 1 If the receiving device does not have enough space to store the incoming Audio Message the regulations in requirement R7 15 2 shall apply When a user plays back an Audio Message it shall be played through the devices internal earpiece telephone speaker or through any other currently active audio output There shall be an option for the user to switch the Audio Message playback to the handset s loudspeaker during playback of the message US8 3 As a user want to find my Audio Messages as part of the Chat Conversation with a specific contact or Group Chat V2 0 R8 3 1 R8 3 2 R8 3 3 R8 3 4 It shall be possible to delete Audio Messages from a Conversation Thread according to requirements defined in the Fil
204. ng or receiving side e g in case of but not limited to if device lost radio coverage the File Transfer shall resume automatically from the point of interruption once the required conditions have been restored e g device is back in radio coverage R7 15 2 lf the receiver s device does not have enough storage space to download the full file R7 15 2 1A notification shall be provided to the receiver before downloading the full file R7 15 2 2Storage space shall be freed up manually by the receiver before download attempt shall be possible R7 15 2 3The user shall have the option to re start the file download as long as the operator storage time as in R7 10 1 has not expired US7 16 As a service provider want to be able to limit the size of the files that are transferred V2 0 Page 89 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document R7 16 1 lf the sending device attempts to send a file larger than the limit for File Transfer the A party shall be notified that the file exceeds the size limit supported by the service NOTE In order to avoid user disappointment caused by different maximum allowed file sizes on different networks it is recommended to align a maximum file size at least on a national level across operators US7 17 As a user want to block specific users so that do not receive any kind of files from them anymore R7 17 1 Incoming File
205. nt US6 22 As a user want to see the timestamp associated with each of my sent and received messages R6 22 1 OM The date and time associated with each chat message shall be displayed adjusted to the current device date and time R6 22 1 1This timestamp shall be generated for sent messages by the device ina consistent way as timestamps are generated for other device functions e g SMS R6 22 1 2Timestamps for received messages shall be based on the UTC timestamp that comes with each message aligned with the selected device time zone US6 23 Asa user want any Group Chat Conversations to permanently reside on my phone and I can resume that group whenever I decide to do so R6 23 1 OM Any participant in a Group Chat Conversation shall be able to send a Chat Message to other participants in the Group Chat at any given point in time R6 23 2 lf the chat application is closed either by manual user interaction e g by selection of another RCS function pressing the home key or switch to another application or phone interaction e g receiving call the connection to the ongoing Group Chat shall be kept In this case the user shall stay in the group continue to receive incoming new messages and resume at any point in time The other participants shall not receive any notification about this procedure R6 23 3 A Group Chat expires in the network when there is no activity in it for a few minutes However when this happens the
206. nt RCC 61 RCS Common Core 1 1 Service Description Document Table of Contents 1 V2 0 Introduction 1 1 Purpose of the document 1 1 1 Structure of the document 1 1 2 Common Core client scope 1 2 Table of references 1 3 Conventions 1 4 Requirement and Technical Realization Classification 1 5 Terms and Abbreviations 1 6 Differences to previous versions Device Provisioning 2 1 Description 2 2 User Stories and Feature Requirements 2 2 1 Configuration of the user s primary device by requesting user identity 2 2 2 Downloadable RCS application Multiple RCS instances 2 2 3 User consent 2 2 4 Secondary Devices 2 2 5 Error Management 2 2 6 Provisioning push 2 3 Technical Information 2 3 1 Technical Implementation of User Stories and Service requirements Capability Discovery and Service Availability 3 1 Description 3 2 User Stories and Feature Requirements 3 3 Technical Information 3 3 1 Overview Operator Messaging 4 1 Description 4 2 User Stories and Feature Requirements 4 2 1 Operator customization variants for representation of Operator Messaging variants on the device 4 2 2 Client Logic to propose the desired Messaging and File Transfer Service Seamless Messaging 4 2 3 Client Logic to propose the desired Messaging Service Integrated Messaging 1 IM_CAP_ALWAYS_ON 0 SMS as default 4 2 4 Integrated Messaging 2 IM_CAP_ALWAYS_ON 1 RCS Chat as default between RCS users 4 2 5 Integr
207. ntact card call logs a lip sync IP video call to a contact i e user B R11 1 1 OM From any call related entry point on a device a user should be able to initiate an IP video call to a contact whenever it is possible R11 1 2 A network operator may connect an IP video call to a secondary interface US11 2 As a user i e user A want to be assured that in case I press the button to initiate an IP video call to a contact i e user B the IP video call can actually happen end to end with a high likelihood so that I do not get disappointed or a perception of an unreliable service R11 2 1 OM The IP video call capability shall be refreshed once a user accesses the screen view containing the IP video call entry point R11 2 2 Capability polling will follow the procedure as described in Capability Discovery and Service Availability page 25 V2 0 Page 118 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document R11 2 3 In case the A Party device does not provide a camera hardware limitation the IP Video Call capability is not given There shall not be a service entry point for upgrading to video R11 2 4 Incase the B Party device does not have a camera built in neither front facing nor rear facing but is able to display video in 352x288 pixel resolution 15 fps or better the A Party shall be able to trigger a 1 way IP Video Call to B Party device B Pa
208. o Call can be technically delivered via Video over LTE ViLTE IR 94 or RCS IP Video Call ViIP The IP Video Call specific behaviour is defined in IP Video Call page 118 US12 11 As a user during a voice call all bearers I i e user A want to upgrade the ongoing call to an IP video call R12 11 1 OM During an ongoing voice call CS VoLTE RCS IP Voice Call a user should be able to initiate an IP Video call that replaces or adds on the ongoing voice call with minimum disruption to the other party R12 11 2A notification shall be displayed to the user in cases where the In Call service is linked with an ongoing CS call that cannot be continued due to a potential switch of voice bearer US12 12 As a user I i e user A want to be assured that in case I press the button to upgrade my call to an IP video call the IP video call can actually happen end to end with a high likelihood so that I do not get disappointed or a perception of an unreliable service R12 12 1OM During an ongoing voice call there shall be an indication of end to end IP video call capability or indication of end to end Video Share capability depending on operator configuration see below R12 12 2 n call capability polling will follow the procedure as described in Capability Discovery and Service Availability page 25 R12 12 3 n case the B Party device does not have a camera built in neither front facing nor rear facing but is able to displ
209. o Messaging and Messaging for Multi device sections NOTE Further improvements to the Messaging for Multi device section Such as introduction of synchronisation triggers are expected once the work of the Multi device Messaging Operator Interest Group has been concluded 2 Device Provisioning 2 1 Description An operator may provision different services for different users and or devices based on internal policies e g having an active subscription to one service In the device provisioning phase the services that are allowed for that user are configured on the device Feature Feature Feature Feature Feature Feature Feature Feature 1 2 3 4 5 x y z All available RCS features Subset of RCS features that are used by MNO Subset of RCS features that a device can support depending on hardware capabilities Subset of RCS features that a device can support depending on specific limiting situations e g weak connectivity low battery available memory Figure 1 RCS features and their availability depending on operator choice device capability and specific limiting situations An RCS service will most likely be activated in one of the following scenarios e As part of the initial phone setup when RCS is natively implemented in a device e Just after downloading the RCS application from any online market to any kind of device e Just after the install of a firmware update including the RCS service Activation may
210. o delete single and multiple non adjacent Chat Messages in a chat thread R5 22 3 The user shall have the option to delete an entire Conversation R5 22 4 Any Chat Messages or entire Conversations that have been deleted by the user shall no longer be available on the Common Message Store NOTE Deletion on other devices of the same identity is described in Messaging for Multi Device page 102 US5 23 As a user I want to be able to forward a single sent or received chat message to one or more Contacts NOTE This may be performed by the user by copying existing message text and pasting into a new Chat message R5 23 1 The user shall have the option to forward a single sent or received Chat Message to one or more contacts NOTE This function may be executed using the copy and paste text editor function of the device US5 24 As a user want to switch to a voice or video call with the B Party during a Conversation and return to chat when the call is finished R5 24 1 The user shall have the option to easily access voice calls from the Chat Ul with the contact in the Conversation After the call has ended the user can return to the Conversation R5 24 2 The user shall be able to receive a voice call when actively engaged in a Conversation and return to the chat when the voice call was ended R5 24 3 The user shall have the option to easily access video calls from the Chat UI with the contact in the Conversation After the cal
211. ociated to requirement US13 7 or R13 8 1 When the user decides that a specific application shall not be discoverable by others contacts this means that the application will no longer apply the procedure described in sections 2 6 1 1 3 and 2 6 1 2 2 6 of RCC 07 for that specific application This requirement needs to be enforced on the client and is up to its implementation R13 18 15 Requirements for user story US13 12 are ensured at the terminal level for the triggering from the address book and at the application level for the triggering within the application At the address book level this is ensured through the procedures defined in RCC 53 At the application level it s up to the application to display this information provided through the API as per RCC 53 R13 18 16 When an application is uninstalled the requirements for user story US13 13 are covered at the stack level by following the procedures defined in section 4 4 4 5 of RCC 53 R13 18 17 The requirements of user story US13 14 are only applicable to applications that use features associated to user story US13 7 or requirement R13 8 2 It Page 142 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document is ensured at the network level and is up to service provider policy Identification of the app registering shall be done via the SIP REGISTER request that conveys the identity of the app through its IA
212. ociation Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document R2 8 7 NOTE 2 2 5 R2 8 8 R2 8 9 After successful completion of R2 8 5 the user shall be requested to enter the password to complete the provisioning process Since the SMS with the password is sent in this case to the primary device but the device to be configured may be a different one the application on the secondary cannot intercept the SMS Therefore this SMS is readable and the user will be requested to go to their inbox get the password and type it in to complete the provisioning In case the user enters and sends a wrong password in R2 8 7 the UI shall respond according to the UI guidelines defined by the individual operator e g display again the text box requesting the password When the secondary device authentication has successfully completed a completion or welcome message should be displayed Error Management US2 9 As an operator want technical errors to be handled with minimal user interaction The user may get any of the following errors R2 9 1 NOTE 1 V2 0 Reception of SMS see R2 1 2 1 R2 8 5 takes too long or is never received There are two possible causes The network does not deliver the SMS 2 The user made a mistake when typing the MSISDN and the SMS is sent to a different device also see R2 8 8 In either case the user shall be presented a screen informing them that
213. omply to the rules of File Transfer Auto Accept as described in File Transfer incl Geolocation Push page 84 fulfilling R8 2 5 e The Store and forward mechanism as defined in File Transfer incl Geolocation Push page 84 will take care of requirement R8 2 6 e The local blacklist mechanism as defined in File Transfer incl Geolocation Push page 84 will take care of requirement R8 2 7 e Management of local storage space as required in File Transfer incl Geolocation Push page 84 will take care of requirement R8 2 8 R8 4 19 Requirement R8 2 9 shall be implemented locally on the device R8 4 20 Requirement R8 2 10 shall be implemented locally on the device 8 3 2 4 Audio Messages are part of the Chat Conversation with a specific contact or Group Chat R8 4 21 As an Audio Message is a file e Deletion as required in File Transfer incl Geolocation Push page 84 is supported fulfilling requirement R8 3 1 e Storage in the Common Message store as defined in File Transfer incl Geolocation Push page 84 is supported fulfilling requirement R8 3 2 R8 3 6 and R8 3 8 e Availability of messaging content on other devices is supported as defined in Messaging for Multi Device page 102 fulfilling requirement R8 3 3 and R8 3 8 e Availability of Audio Messages from the Chat and Group Chat conversation follows the one defined for File Transfer as required in File Transfer incl Geolocation Push
214. on 3 12 4 2 1 1 of RCC 07 If the communication is real time based using the RTP protocol the app shall follow the procedures defined in section 3 12 4 2 1 2 of RCC 07 At the Terminal level through the procedures defined in RCC 53 R13 18 11 For requirement R13 8 2 and R13 8 3 the following applies At the U NI level an app can set a communication with any other RCS entity which does not have specifically the same app using an RCS service by following the procedu res defined in section 3 12 4 1 of RCC 07 At the terminal level through the procedures defined in RCC 53 R13 18 12 For services configuration of requirement 13 6 1 2 this is ensured through procedures described in RCC 53 R13 18 13 Requirements of user story US13 9 is only applicable to applications that use features of requirements of user story US13 7 or requirement R13 8 1 The discovery is performed via the standard capability exchange mechanism see Capability Discovery and Service Availability page 25 Each app is uniquely identified by an IARI as defined in sections 2 6 1 1 3 and 2 6 1 2 6 of RCC 07 An app shall not be granted access to trigger a capability exchange itself However the app may have access to the result of a prior capability exchange R13 18 14 Requirement for user stories US13 10 and US13 11 are ensured at the application and stack level These requirements are only applicable to applications that use features ass
215. on 4 R4 11 2 The RCS client will not show or visually indicate to the user the technology service used to convey the message from the device R4 11 3 The operator can interwork any message sent from the RCS device regardless of technology service to ensure the best possible message delivery to an intended recipient 4 2 2 Client Logic to propose the desired Messaging and File Transfer Service Seamless Messaging US4 12 As auser want to fully rely on my operator to convey the Messaging Service to ensure quickest and most reliable message delivery R4 12 1 The Seamless Messaging composer shall select RCS as the Messaging and File Transfer Service when no network connection is available and not registered for RCS services These messages shall be queued for delivery when the device is reconnected The user shall be notified that these messages are queued for delivery R4 12 2 When the device is connected to cellular coverage without data not registered to the RCS platform the delivery mechanism from the Seamless Messaging App shall be SMS NOTE All other RCS services will not be available R4 12 2 1lf the user selects other RCS services non text messaging when in this mode these messages will be queued for delivery when the device is reconnected The user shall be notified that these messages are queued for delivery R4 12 3 When the device is connected to cellular coverage with data but not registered to the RCS platfo
216. onality and or process is Mandatory Required These terms dictate that a functionality and or process is Mandatory l i a a 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 5 Terms and Abbreviations Term Description contains technical and functional terms 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 Active device or device interface A session is established and associated with that interface 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 V2 0 Page 7 of 166 GSM Association Official Document RCC 61 RCS Common Core 1 1 Service Description Document Term Description contains technical and functional terms Non confidential Aggregation of dev
217. only be available if offered by the operator if Wi Fi capability is enabled on the device the device is attached to a public or private Wi Fi access point and the Wi Fi access point has connection to the operator voice service US15 2 As a user want to use Operator Messaging Services irrespective of my chosen connectivity conditions R15 2 1 NOTE V2 0 R15 2 2 R15 2 3 R15 2 4 R15 2 5 R15 2 6 R15 2 7 R15 2 8 The operator shall be able to zero rate data traffic which is induced by Operator Messaging and meter events instead Signalling that is used for production of Operator Messaging shall be in the background and hidden from the user i e also not metered Operator Messaging over cellular shall be disabled by the device in flight mode Usage over Wi Fi may be possible if offered by the operator and allowed by the airline RCS Messaging as part of Operator Messaging shall be based on operator configuration see R15 4 2 available over the cellular network when the cellular data switch is switched off The SMS service shall be available whenever the device is registered to a cellular network In domestic case and in roaming the operator tariff scheme for Operator Messaging services applies The operator MMS service shall be available whenever the device is registered to a cellular network The various device settings for MMS e g but not limited to MMS auto acceptance MMS auto acceptance in
218. orcing user input of the OTP as defined in section 2 3 5 of Client configuration transactions carrying user data are encrypted via TLS SSL as defined in sections 2 2 5 of R14 4 5 2HTTP s based client configuration on non 3GPP access for primary and for additional devices makes use of either based on the GBA 1 primary device only or the authentication method 4 as defined in sections 2 3 2 5 and 2 6 of Client configuration transactions are encrypted via TLS SSL as defined in 2 3 3 2 5 of RCC 07 R14 4 5 3The authentication method for IMS access depends on the mode and capability of the RCS device the type of access and the device configuration The client shall apply the authentication in IMS as defined in section 2 13 1 2 of RCC 07 The encryption of SIP signalling is determined by client configuration as defined in section 2 8 of RCC 07 and 2 2 2 2 of RCC 15 The authentication method for HTTP transaction of File Transfer over HTTP shall be based on digest authentication 2 based on the credentials received by the client via device configuration as defined in sections 3 5 4 8 1 of RCC 07 HTTP File Transfer transactions carrying user data are encrypted via TLS SSL as defined in 3 5 4 8 5 of RCC 07 R14 4 5 4The authentication method for IMAP sessions for the Common Message Store either based on AKA based on the GBA 1 or is based on basic authentication 2 with the CMS credentials received by the client
219. ording to section 3 4 4 1 8 of RCC 07 e Specific content generated by Extension see API Extensions page 136 shall not be stored in the Storage Server as per section 3 12 4 2 1 1 of RCC 07 e The Message Store client shall follow the clarifications given in section 3 2 6 2 of RCC 07 e The Message Store client shall follow the synchronization guidelines defined in section 3 2 6 2 8 of RCC 07 V2 0 Page 108 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document 9 3 3 e The Message Store client shall apply the mechanism to correlate legacy SMS MMS messages with the same messages already stored in the Common Message Store as per sections 3 2 4 7 1 to 3 2 4 7 4 of RCC 07 Requirements matching R9 5 7 Multi device Messaging see user story US9 1 shall be done as described in sections 3 2 3 3 3 4 and 3 5 of RCC 07 R9 5 8 Requirement R9 1 1 is mainly ensured via the devices or interfaces implementation that knows whether this is a primary or secondary device see definitions As specified in section 2 5 1 of the first time configuration of the RCS capable device or interface is linked to the primary SIM card of the user Table 12 of also indicates that the MSISDN of the primary SIM is used to derive the user s main identity R9 5 9 Requirement US9 2 is controlled through provisioning see Differences to previous versions RCS Common Core 1
220. ory US4 5 shall be implemented locally on the client The requirements listed under user stories US4 6 through US4 16 shall be implemented locally on the client The following general procedural requirements shall be considered For the requirements where a client needs to determine the RCS registered status of the other party via capability discovery the client implementation shall take the definitions of the automata tag in section 2 7 1 1 of RCC 07 into account For the requirements where a client needs to determine the messaging technology based on the network connection status and the device is in a situation where it attaches to the network anew e g due to power on or resume from airplane mode it is recommended that the client awaits the completion of all network attach procedures first The determination of the integrated seamless messaging capability of other RCS users is provided by the capability discovery of the Combined Messaging UX as defined in section 4 3 3 page 60 If the DELIVERY TIMEOUT timer expires for a chat message or a File Transfer the client shall either initiate a capability discovery to determine whether messaging technology is to be switched or inform the user as defined in the operator messaging requirements 5 1 to 1 Chat 5 1 Description 1 to 1 Chat enables users to exchange chat messages with another party This section describes the User Stories and Service Requirements for the core chat serv
221. oup Chat Notifications the user shall be forwarded to the list of Group Chat Conversations In this case the unread message visual identifier shall be removed once the last new message was read Alternatively the OEM may handle it differently on the device e g the visual notification disappears already after selecting the notification and seeing the list of Group Chat Conversations The visual notification shall be permanently removed after the user has opened the message US6 16 As a user want to be able to mute individual Group Chat Conversations which results in silencing any audible notification or vibration on incoming new Group Chat Messages or notifications on joining leaving participants from that specific Group Chat Conversation V2 0 R6 16 1 The user shall be able to mute selected Group Chat Conversations i e no audio or vibrate notification shall be performed on incoming new messages within the selected Group Chat Conversation Page 75 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document NOTE This selection does not have any effect on notifications in any other than the selected Group Chat Conversation US6 17 As a user want to see the subject title and Group Picture as the identifier of a Group Chat Conversation in the list of Chat and Group Chat Conversations R6 17 1 Any Group Chat shall be represented with Subject title and Group Picture
222. p to Service Provider s policies and implementation R11 18 11Requirement US11 7 including R11 7 1 is subject to Technical Enabler employed TE1 or TE2 as described in section 11 3 1 and on network conditions e g device IP Address and port maintenance after moving out of LTE availability of secondary PDP context NOTE Requirement R11 7 1 is not implementable if TE1 is used R11 18 12Requirement US1 1 8 including R11 8 1 shall be implemented locally in the device R11 18 13For requirement US11 9 R11 9 1 and R11 9 1 1 the following shall be considered e TE1 Section 2 4 4 of PRD IR 92 and section 2 4 of PRD IR 94 shall be taken into consideration Note that in the particular case the underlying VoLTE call cannot be maintained Annex A of PRD IR 92 shall be considered e TE2 Sections 3 8 and 3 9 4 1 1 of RCC 07 Note that the continuity is subject network conditions e g device IP Address and port continuity R11 18 14Requirements US11 10 R11 10 1andR11 10 2 US11 11 R11 11 1 US11 13 R11 13 1 and R11 13 2 US11 14 R11 14 1 and US11 17 R11 17 1 R11 17 2 R11 17 3 and R11 17 4 shall be implemented locally in the device NOTE Requirements R11 4 3 and R11 10 1 the stop video transmission is implemented as described in section 2 2 2 PRD IR 94 which is applicable V2 0 Page 123 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document both to
223. pation of the user R6 26 4 Re joining a previously left Group Chat Conversation shall be possible by the user being re invited by another still active Group Chat participant V2 0 Page 78 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document NOTE This requirement shall only apply to Open Group Chats US6 27 As a user want to use the text editing tools of the device that are available on my device e g but not limited to copy paste edit for chat messages NOTE In case of the user trying to paste an image into the text editor the device may ignore the user action R6 27 1 The user shall have the option to select text e g from a message a website or any other text source and use text editing tools such as copy amp paste to create messages US6 28 As a user want to select and delete single and multiple nonadjacent chat messages in a Group Chat thread R6 28 1 The user shall have the option to delete a single Chat Message from a Group Chat Conversation R6 28 2 The user should have the option to delete single and multiple nonadjacent Chat Messages from a Group Chat Conversation US6 29 As a user want to delete complete Group Chat Conversations R6 29 1 The user shall have the option to delete an entire Group Chat Conversation Deleting an entire Group Chat Conversation shall automatically trigger leaving the Group Chat US6 30 As a user want to
224. pecifications as according to section R9 5 4 the File Transfer request will be forked to all devices The devices that are not in an active chat session have no way to know that Page 111 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document another device is still in a session thus allowing to have a special processing regarding auto acceptance A service provider may implement a proprietary solution to cover this requirement R9 5 29 Requirement R9 3 20 shall be fulfilled based on service provider policy R9 5 30 Requirement R9 3 21 is partially covered not feasible in all situations by the procedures of section 3 4 4 1 3 1 of RCC 07 The requirement can only be covered in case the client where the explicit departure is triggered is connected to the focus see Group Chat page 71 R9 5 31 Deletion as required by R9 3 22 is one of the actions covered by the synchronization with the Common Message Store see section 6 3 5 of RCC 09 When a user wants to delete information related to a conversation from one of their devices the device on which the action is triggered shall store Deleted flag on the related objects in the Common Message Store as per Annex B 4 5 of RCC 07 R9 5 32 Requirement R9 3 22 1 shall be implemented locally on the device R9 5 33 Requirements on deletion R9 5 33 1 Requirement R9 3 24 shall be implemented by the system by simply deleting th
225. pending R4 13 4 3When the A Party goes offline during an ongoing chat conversation pending chat messages i e those the user has attempted to send but have not yet become sent shall be queued and marked as pending The user shall be able to retry manually the sending of one or all of these messages by xMS R4 13 4 4When a DELIVERY TIMEOUT expires for these pending chat messages they shall be considered as failed The user shall be able to retry manually the sending of one or all of these messages by xMS or via chat if it becomes available again R4 13 4 5 The user shall be notified about pending chat messages e Inside the message thread through an indication in the thread message status indication e Inthe messaging inbox the visual indication should be used in both the message inbox view and the message thread view e Outside the message thread or inbox notification shall not be displayed to the user R4 13 4 6 The user shall be notified about failed chat messages e Inside the message thread through indication in the thread message status indication e Inthe messaging inbox the same visual indication should be used in both the message inbox view and the message thread view e Outside the message thread or inbox through a system notification The notification shall inform the user that some messages are faled and will not be sent e Opening the notification shall forward the user to the
226. presented at key touch points on the device where RCS communications can occur specifically R3 3 3 1 Service entry points for voice call shall always be visible and selectable at any given point in time The service entry point for RCS IP Voice Call and CS VoLTE may appear differently however only one service entry point style shall be shown at a time R3 3 3 2 Service entry points for messaging shall always be visible and selectable at any given point in time This requirement shall be applicable for Group Chat as well R3 3 3 3 Service entry points for File Transfer shall always be visible and V2 0 selectable at any given point in time This requirement shall be applicable for all services that use File Transfer as an enabler Audio Messaging vCard sharing and Geolocation Push Page 26 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document R3 3 3 4 For IP Video Call the operator shall have the option to configure the device behavior on a per device basis in one of the following ways R3 3 3 4 1 Variant A The IP Video Call service entry point shall be visible and selectable by the user if there is a high likelihood that the IP Video Call attempt will be successful at that time If an IP Video Call is unlikely to be successful the IP Video Call service entry point shall be greyed out and not selectable This variant applies for any phone number including RCS a
227. pted the audio part shall be played either via a connected headset if connected or via the external loudspeaker if no headset connected 12 2 4 Share any file during call The functionality to share any file during a call is basically based on File Transfer that happens usually within the context of messaging Sharing during a call therefore happens within the context and user flows of the ongoing voice or video call US12 20 As a user while in a voice or video call i e user A want to share any file from my in call screen with the other participant of the call i e user B whenever it is possible R12 20 1 OM File Transfer shall be possible during an ongoing voice CS VoLTE RCS IP Voice Call or video ViILTE RCS IP Video Call call while the call shall continue seamlessly on the same bearer V2 0 Page 130 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document NOTE This includes the case where other in call services are also in progress R12 20 2 During a voice or video call user A should be able to send a file to user B to directly from the in call screen NOTE This includes the case where other in call services are also in progress R12 20 3 The support of file types and file sizes shall follow as specified in File Transfer incl Geolocation Push page 84 R12 20 4 lmages and videos shall be able to be resized as specified in File Transfer incl
228. push configuration settings in special cases Network initiated configuration request Provisioning push will allow an operator to force the reconfiguration of each user s device if needed R2 10 1 R2 10 2 R2 10 3 The operator shall be able to push configuration settings to new or existing RCS users e g in the case of changing parameters The operator shall be able to push configuration settings in case the network is upgraded to a new RCS release The operator shall be able to push configuration settings when the device is permanently disabled but the user would like to start using RCS 2 3 Technical Information 2 3 1 V2 0 Technical Implementation of User Stories and Service requirements R2 11 1 R2 11 2 R2 11 3 R2 11 4 R2 11 5 Provisioning on networks with automatic identification see requirement R2 2 1 shall be done as described in RCC 07 section 2 3 3 1 and 2 3 3 2 with only the Hyper Text Transfer Protocol HTTP solution being in scope as it is also needed when configuring over networks where identification is not possible see R2 11 2 For the HTTP based mechanism section 2 3 3 2 of RCC 07 and its subsections shall apply in their entirety If the network cannot authorize the user as described in requirement R2 2 2 an HTTP 511 Response shall be returned as indicated in section 2 2 4 of which shall as indicated in result in the use of the procedures in section 2 3 of In that case if the I
229. quirements for user story US5 13 e Group Chat o Additional requirement introduced to allow the user to see who set up the Group Chat see requirement R6 6 2 e IP Voice Call o Additional user story included to allow the user to see what the call bearer is in use for the call see requirements for user story US10 12 e Introduction of LED notifications for received one to one group chat and file transfer messages e Editorial clarifications to Audio Messaging and Messaging for Multi device sections NOTE Further improvements to the Messaging for Multi device section such as introduction of synchronisation triggers are expected once the work of the Multi device Messaging Operator Interest Group has been concluded Device Provisioning page 10 R16 1 1 A RCS Master Switch shall be available to activate deactivate the native RCS functionality on the device R16 1 2 There shall be various entry points on the device for the Master Switch for example e Wireless and Networks settings on the device if available e Messaging gt Settings if implemented e Messaging gt Settings gt Chat Service if implemented R16 1 3 If the Master Switch is visible from more than one location on the device then the implementation shall be consistent i e if the Master Switch is changed in one location the change shall be consistent for all locations V2 0 Page 156 of 166 GSM Association Non confiden
230. r primary devices that use the IMS or HOSAPN for RCS see ALWAYS USE IMS APN in section A 1 12 of RCC 07 and RCS VOLTE SINGLE REGISTRATION in IP Voice Call page 113 the complete behaviour is applicable R15 5 1 2TE2 For primary devices that use the internet APN for RCS see ALWAYS USE IMS APN in section A 1 12 of RCC 07 and RCS VOLTE SINGLE REGISTRATION in IP Voice Call page 113 the connectivity when data is switched off would be handled based on the provided value of the RCSE ONLY APN as described in section 2 9 1 4 of RCC 07 The data off behaviour is applicable only when an RCSE ONLY APN is configured R15 5 1 3Secondary devices Those are access agnostic and as a result the behaviour described is not applicable to such clients When the cellular data switch is switched off they would have no data connectivity on cellular networks and as a result in those circumstances they shall not be able to offer any operator services on such networks R15 5 2 For requirement R15 1 1 PS voice services shall be available if allowed by configuration see IP Voice Call page 113 supported by the current network coverage and allowed based on the current data off setting see R15 5 21 If PS voice services are not allowed a CS voice call shall be possible when the device is connected to a cellular 2G 3G network When connected to an LTE network calls can in that case be provided through Circuit Switched Fall Back A CS voice ca
231. re shall be followed as specified in the Video Share section 12 2 3 Image Share Image Share is a service that allows sending a picture either stored in a user s device or taken for the purpose while in a voice call with a contact The service differs from File Transfer only in terms of user experience and interface Sharing during a call given the real time context is an immediate task with minimal user interaction displaying the shared content within or on top of the calling screen US12 16 As a user in a voice call i e user A want to send a picture from my in call screen either stored in a user s device or taken for the purpose to the other participant of the call i e user B whenever it is possible R12 16 1OM A user shall be able to transfer a picture to the other conversation party during an ongoing voice call CS VoLTE RCS IP Voice Call while the voice call shall continue seamlessly on the same bearer R12 16 20M In case the underlying voice call is terminated Image Share shall be terminated as well V2 0 Page 129 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document US12 17 As a user want the option to resize pictures before sharing in order to limit transfer volume memory need and transfer time NOTE resize means changing the picture size to a high medium and low size of the picture R12 17 1 OM Selecting image share shall offer the
232. receive voice calls with my primary device in areas without sufficient cellular reception R10 2 1 RCS IP Voice Call services should be available from primary devices R10 2 2 RCS IP Voice Call on primary devices may be delivered on a best effort basis i e no commitment on quality of service QoS or mobility may be offered by the MNO NOTE RCS IP Voice Call aims at providing a high quality voice call to users US10 3 As a user i e user A want to make and receive voice calls with my secondary devices i e which do not have cellular voice call capabilities R10 3 1 RCS IP Voice Call service should be available from secondary interfaces R10 3 2 RCS IP Voice Call on secondary devices may be delivered on a best effort basis i e no commitment on quality of service QoS or mobility may be offered by the MNO NOTE RCS IP Voice Call aims at providing a high quality voice call to users V2 0 Page 113 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document US10 4 As a service provider want RCS IP Voice calls and Voice over LTE calls exclusive to each other so that VoLTE is used whenever supported even if RCS IP Voice call is technically possible R10 4 1 For the cases that a primary device is under a network that supports both VoLTE and RCS IP Voice call VoLTE calls prevail NOTE Such cases shall not exist since RCS IP Voice call is per definition onl
233. rm the sending mechanism from the Seamless Messaging App shall be xMS NOTE Restrictions in file size and type for MMS apply V2 0 Page 42 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document R4 12 4 When the device is registered for RCS service the delivery mechanism from the Seamless Messaging App shall be RCS NOTE This shall also be valid for RCS messages service to non RCS enabled contacts R4 12 5 When the device is registered for RCS service and the sent RCS message times out due to a loss of IP connectivity the RCS client application may attempt to resend the RCS message in SMS mode without notifying the user or the RCS client application may visually display a message sent error to the user R4 12 6 When the device is registered for RCS service and the DELIVERY TIMEOUT parameter is enabled the RCS client application shall attempt to resend a RCS message in xMS mode when the DELIVERY TIMEOUT timer expires before confirmation of a message delivered state Seamless Messaging Selected Messaging Service ace to Cellular network User A Sender ConnecttoRCS to RCS alll to Cellular network ah User B Receiver ConnecttoRCS RCS Selected Service xms On device caching of unsent files required and user shall be informed Table 11 Table to explain and summarize static conditions for Seamless Messaging 4 2 3 Client Logic to propose the desired Me
234. rty obviously shall have no option to activate the video channel back to A Party R11 2 5 In case the B Party device does not have a camera built in neither front facing nor rear facing and is not able to display video in 352x288 pixel resolution 15 fps or better the A Party shall not be able to trigger an IP Video Call to B Party US11 3 As a user I i e user A want to be able to initiate an IP video call using a single start video call button irrespective of network bearer used R11 3 1 There shall be only one button displayed to the user to initiate an IP video call irrespective of the actual network bearer NOTE CS Video Call shall not be offered as part of this one button experience R11 3 2 The network operator may configure on which network bearers an IP video call shall be made available US11 4 As a user receiving an incoming IP video call i e user B want to decide whether to a Decline the call which leads to an unanswered video call indication to the calling party i e user A b Accept the call without transmitting my camera view or c Accept the call with transmitting my camera view R11 4 1 OM The receiver shall be able to accept or decline an incoming IP video call R11 4 2 Upon decline by the receiver the incoming call shall be handled as configured in the specific call forwarding settings for video calls This depends on B Party operator specific enablers on whether this is offere
235. rvice At any time during the process selecting and sending a message or file the client logic shall propose a Messaging or File Transfer Service either xMS based or RCS based to be used for that message or file If the available technology changes while the user is in the process of composing a message or selecting a file any impact of the technology change Page 40 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document R4 9 10 NOTE R4 9 11 R4 9 12 R4 9 13 NOTE R4 9 14 NOTE R4 9 15 on the available message content must be made clear to the user and they shall be able to reject the automatic technology change After sending a message or file the device UI shall differentiate the Messaging or File Transfer Service that was used Differentiation shall allow the user to know which messaging i e chat SMS or File Transfer i e RCS File Transfer MMS service was used to convey the message The RCS File Transfer service should be clearly differentiated from MMS Where appropriate the user should be made aware of any additional or enhanced File Transfer functionality available via RCS vs MMS for example but not limited to the transfer of HD video When receiving a message or file the device UI should differentiate the Messaging or File Transfer Service that was used Differentiation shall allow the user to know which messaging i e
236. ry US9 3 is covered via the endorsement of OMA CPM as defined in RCC 09 RCC 11 and section 3 2 4 7 of RCC 07 Requirements R9 3 1 R9 3 2 R9 3 3 and R9 3 4 are provided by the use of the Common Message Store and the synchronization of clients as described in section R9 5 6 to complement the information received in live communications SMS R9 3 4 1 MMS R9 3 4 2 Chat messages R9 3 4 3 Group Chat messages R9 3 4 4 and files R9 3 4 8 are processed according to RCC 09 RCC 10 and RCC 11 As vCard R9 3 4 6 and Audio Messages R9 3 4 7 are seen as File Transfer specific Content see section 3 5 1 1 of RCC 07 they are also covered Geolocation push R9 3 4 5 based on File Transfer and Chat is also covered Requirement R9 3 5 shall be implemented locally on the device SMS and MMS are stored in the network and are processed according to the MNO s policy The requirement R9 3 6 shall be implemented locally on the device Triggers for synchronization as defined in section 3 2 6 2 8 of RCC 07 are defined to cover requirement R9 3 6 See also section R9 5 6 Requirement R9 3 8 can be covered with the current RCS specifications see RCC 07 It is up to the device implementation to fetch messages starting with the most recent one Requirement R9 3 9 shall be implemented locally on the device Page 110 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description
237. s based on this subscription The user alias for Group Chat users described in user story R6 5 3 and R6 5 4 is implemented as defined in section 2 5 3 3 of RCC 07 R6 37 6 The client implementation shall ensure that the invitation to a Group Chat does not require explicit user input to accept it as required in user story US6 6 However the service provider is able to define the technical procedure of the client to accept an invitation to a Group Chat by use of the configuration parameters IM SESSION AUTO ACCEPT GROUP CHAT as defined in section A 1 4 3 of RCC 07 R6 37 7 For the requirements of user story US6 7 in order to send text to a conversation while a Group Chat exists the client shall send the message using this session If no session exists the client shall restart the Group Chat as defined in section 3 4 4 1 7 and send the message to it R6 37 8 The client shall not implement client Ul procedures to accept reception of messages or group chat invitations to fulfil the requirements of user story US6 8 R6 37 9 The requirements of user story US6 8 is fulfilled by means of the Group Chat Store and Forward functionality section 3 4 4 3 of RCC 07 R6 37 10 The requirements related to the list of participants defined in user story US6 9 are implemented on the client via the subscription to the conference event package as defined in section 3 4 4 of RCC 07 As a result the client is continuously notified about the conference st
238. s clicked the notification or has accessed the thread from the messaging application Any audible or visual notification shall be suppressed in case the reception is visible on the currently active screen of the device e g if the user is currently on the chat screen with a person and a File Transfer is received For notification of a new incoming location or position the above mentioned requirements shall be valid accordingly Geolocation Push feature is technically using File Transfer mechanisms If the device supports a notification LED for screen off notification then this LED shall flash as long as there are un opened RCS File Transfers The colour should differentiate from notifications from other applications but may be identical for all Operator Messaging services US7 12 As a user want to receive incoming files within a new or existing Chat or Group Chat Conversation As a user want sent and received files to be part of the Chat or Group Chat Conversation thread in similar order and appearance of chat messages but representing the transferred content R7 12 1 R7 12 2 V2 0 Incoming files shall be displayed within a new or existing Chat Conversation Files shall be threaded in the conversation as an event similar to chat messages The same ruling for order of messages as specified in 1 to 1 Chat page 61 and Group Chat page 71 shall be applied to Files Page 87 of 166 GSM Association Non confi
239. s done on the network level US7 8 As a user want to be able to cancel files while the sending process has not been completed yet R7 8 1 The device shall provide the user with the option to cancel a File Transfer while the file is still in the process of being sent on the originating leg NOTE Once the File Transfer on the originating leg is completed it is not possible for the sender to stop the process of File Transfer US7 9 As a user want to transfer a file with my Contact s even when they re temporarily offline e g device switched off expect them to receive the file when they come online again R7 9 1 OM In case the B Party is currently not registered on the RCS service remark offline the request to deliver the file shall be delivered to the B party device once the user is registered again on RCS online NOTE This requirement refers to the store amp forward feature R7 9 2 OM lf a user attempts to download a file that has expired from the network storage they shall be informed that the file is no longer available NOTE This requirement relates to the store amp forward feature US7 10 As a service provider want to limit how long a file is available on the network for offline users R7 10 1 The operator shall be able to define the network storage time for File Transfers that have not been downloaded yet NOTE This requirements relates to the store amp forward feature V2 0 Page 86 of
240. s if the string is the only characters of the message content NOTE The basic set of Emoticons is listed in the Annex Emoticon conversion table page 164 V2 0 Page 62 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document R5 3 3 OM Emoji shall be interpreted as detailed in the conversion table in the Annex of this document The graphical elements that are used may vary from vendor to vendor but the conveyed meaning must not be changed R5 3 4 OM Emoticons from the basic set of Emoticons which are received in Chat Messages shall be converted to graphics if they were separated by blank spaces in messages e g converts to or without the blank spaces if the emoticon string is the only characters of the message content US5 4 As a user want to use the text editing tools of the device that are available on my device e g but not limited to copy paste edit for chat messages NOTE In case of the user trying to paste an image into the text editor the device may ignore the user action R5 4 1 The user shall have the option to select text e g from a message a website or any other text source and use text editing tools such as copy amp paste to create messages US5 5 As a user want to see when the other party is currently writing a Chat Message R5 5 1 OM The other party shall be able to see an is typing notification whenever a new Chat M
241. sage until the first SIP success response is received from the network For File Transfer over HTTP when the user presses ENTER to send the message until the first HTTP POST success response is received from the network The File Transfer may be in this state for some time when the user is NOT registered with the IMS core e g offline or airplane mode Progress For File Transfer over MSRP from the reception of the first SIP Response is received from the network until the final MSRP 200 OK is received For File Transfer over HTTP from the reception of the first success HTTP response from the network until a provisional response is received from the network for the SIP INVITE or a MSRP 200 OK is received from the network for the chat message carrying the File Transfer via HTTP message body content Cancelled If the user has cancelled the File Transfer and the client did invoke the user story US7 8 Sent For File Transfer over MSRP when receiving the final MSRP 200 OK For File Transfer over HTTP when receiving the provisional response for the SIP INVITE or a MSRP 200 OK for the chat message transferring the File Transfer via HTTP message body Delivered For File Transfer over MSRP without store and forward same as sent For File Transfer over MSRP with store and forward when receiving the delivery notification For File Transfer over HTTP when receiving the display notification Failed When a notification that t
242. sation Since communication from a user point of view shall always work across the entire contact list it is essential to ensure the listed in call services are supported end to end also across operators However the network support of the individual in call services is at the discretion of each operator by enabling disabling each service upon provisioning 12 2 User Stories and Feature Requirements 12 2 1 General US12 1 As a user during a voice video call want to use enhanced functionality that allows me to have a more meaningful and engaging i e richer conversation with the person am on the call with R12 1 1 Allin call services shall be made accessible from the in call screen which is by definition only shown during an ongoing call R12 1 2 OM All services shall be delivered in a 1 to 1 call only as there is no multiparty sharing provided R12 1 3 OM The user shall be able to recognise whether the individual in call services are available to use with the conversation partner These capabilities need to be updated for both ends real time V2 0 Page 124 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document R12 1 4 An operator may require a charging indication to be displayed whenever an In Call Service is used by a user can be displayed only one time 12 2 2 Live Video In addition to the Video Share feature of previous RCS versions this
243. scribed in requirement R2 9 4 the service provider can include a message as described in section 2 2 3 of in a response disabling the RCS client i e RCS DISABLED STATE set to 1 R2 11 23 As described in section 2 2 4 of a number of consecutive internal errors each resulting in a temporary unavailability as described in requirement R2 9 1 shall lead to a permanent unavailability As described in section 2 3 4 for non cellular networks this situation shall be applicable only to that particular network however R2 11 24A SMS shall be sent to the device with a specific format defined in section 3 1 and 3 2 of respectively for the push request for initial configuration of a device on which RCS was permanently disabled i e as a consequence of R2 11 23 and R2 11 24 required in R2 10 1and R2 10 3 and a reconfiguration of an active RCS device required in R2 10 1 and R2 10 2 shall be enough to trigger a new configuration of a primary device R2 11 25For the reconfiguration of primary and additional devices on which RCS is active already required in R2 10 1and R2 10 2 it shall be possible to trigger a reconfiguration by sending an End User Confirmation Request to the device as specified in section 2 1 3 1 of RCC 15 RCC 07 3 Capability Discovery and Service Availability 3 1 Description The capability discovery is a process which enables RCS users to understand the set or subset of RCS services their contacts use at certain poin
244. scriber Integrated Services Digital Number i e mobile phone number OEM Original Equipment Manufacturer rer A user who is known to be RCS enabled and not currently registered to the offline user RCS service Communication or signalling that does not go across the interworking interface On Net NNI between networks or networks operators PENE A user who is known to be RCS enabled and is currently registered to the RCS online user service Integration of all Operator Messaging Services into one single application Operator Sel a There are two options for Operator Messaging Integrated Messaging and Messaging a we Seamless Messaging Operator One or more services from traditional messaging services SMS MMS or RCS Messaging services Chat File Transfer Audio Messaging vCard Push Geolocation Services Push enma aiki Device which contains the SIM that matches the identity which the client uses or primary to register in IMS Interface 9g V2 0 Page 9 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document Term Description contains technical and functional terms RCS Alias A name that is defined by the user that represents the user as a Chat name participant on B Party devices if no Contact exists in the contact list RCS enabled Capable of the RCS service activated and ready to operate when the network conditions allow
245. scription RCS APIs enable operator developers MNOs Apps OEM developers OEM Apps and developers from companies outside of the operators Third party apps to integrate RCS V2 0 Page 136 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document features into their applications APIs can be used by all these three different parties to enrich their applications with RCS functionalities and build extra functionality on top of the native out of the box RCS experience MNOs leverage in house operator developers OEM developers and developers from companies outside of the operators to propose innovative user experiences which increase RCS use and data traffic and introduce new service extensions independent of OEM involvement This document covers requirements for all APIs available across any device and network NOTE The scope of API access is at first limited to MNO and OEM apps only However the enablers put in place for this OEM MNO API access shall be extensible to support Third party access in the future This means that access to Third party apps running on an MNO s network can be opened by that MNO at their own discretion NOTE In this document developer means either OEM application developer MNO application developer or Third party developer 13 2 User Stories and Feature Requirements US13 1 As a user want to be able to install apps which use RCS APIs US
246. scription Document R7 23 1 f the current position shall be sent the location shall be automatically detected and suggested to the end user R7 23 2 The user shall have the option to preview and correct the automatically detected position on a map view before sending R7 23 3 The Geolocation Push Service shall support sending of a location that was picked from the map US7 24 As a user want to tag positions or locations with a text field R7 24 1 The user shall have the option to tag a position or location with a free text field before sending US7 25 As a user want to receive positions locations in a map view As a user want to use standard map functions e g guide me to feature NOTE These functions are not provided by the RCS implementation R7 25 1 OM When receiving a position or location the RCS Geolocation Push user shall have the ability to see the position location on a map R7 25 2 OM When receiving a position or location the RCS Geolocation Push user shall be able to see any tags that were added by the sender R7 25 3 When receiving a position or location the RCS Geolocation Push user shall be able to use map and navigation tool functions such as guide me to feature NOTE The compliance with this feature may depend on the capabilities of the receiving handset R7 25 4 When receiving a position or location the legacy non RCS or RCS without Geolocation Push Service user should receive
247. service contacts from the contact list and invite them to the Closed Group Chat R6 1 4 OM Any for this service capable RCS user shall be able to participate in an Open Group Chat Conversation when invited R6 1 5 OM Any for this service capable RCS user shall be able to participate in a Closed Group Chat Conversation when invited R6 1 6 The network operator shall be able to set a maximum number of participants in a Group Chat Conversation NOTE It is beneficial for proper RCS Interworking that RCS operators align on the maximum number of participants at least at a local level R6 1 7 It shall only be possible to set up a new Group Chat Conversation if the initiating user is connected to the RCS platform US6 2 As a user I want to add a subject title to any Open or Closed Group Chat Conversation R6 2 1 When Creating a Group Chat Conversation it shall be possible for the initiator to define a subject title R6 2 2 OM If no subject title has been defined the application shall automatically generate a subject title e g list of users on the Group Chat Liz Thomas plus 3 others R6 2 3 OM It shall be possible to maintain more than one Group Chat with identical Group Chat subject titles V2 0 Page 71 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document US6 3 As a user want to add a contact from my contact list to an existing Open Group Chat Conversat
248. ssaging Service Integrated Messaging 1 IM_CAP_ALWAYS_ON 0 SMS as default US4 13 As a user want the best Messaging Service to be proposed to me to convey my messages R4 13 1 The preferred messaging service for composing and sending messages shall be determined by a number of factors including bot not limited to the RCS Online Offline status of the sender A Party and the receiver B Party NOTE See requirement R3 3 7 5 for Capability Validity and checking requirements Neither A Party nor B Party s cellular connectivity is relevant for determining the preferred messaging service 4 2 3 1 Entering a new or existing conversation The preferred messaging service is automatically determined according to rules described below R4 13 1 1 Preferred Messaging Service when entering a new or existing conversation including but not limited to opening a conversation returning to a conversation and unlocking the screen on an open conversation V2 0 Page 43 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document R4 13 1 1 1 lf a valid Capability check is available when opening the conversation then the preferred service is set accordingly R4 13 1 1 2 lf a new Capability check is required then xMS is the preferred service until the result of this new capability check is available If the result of this new Capability check is that the B Party is RCS Online th
249. ssion exists for the conversation the user is typing in The requirements of user story US5 6 shall be implemented as defined in section 3 3 4 of RCC 07 As a Clarification of the user story US5 7 it shall be noted that the client shall Not apply any procedures for the acceptance of the delivery of single messages If the first message is carried in a SIP INVITE then the client should enforce the chat session auto accept policy of the service provider as defined via the configuration parameters IM SESSION START and SESSION AUTO ACCEPT defined in section A 1 4 3 of RCC 07 In all other cases the device shall rely on the value of the SESSION AUTO ACCEPT parameter which needs to be set by the service provider to 1 to enforce the client to accept the session immediately The store and forward functionality defined in user story US5 8 shall be implemented as defined in sections 3 3 4 1 4 and 3 3 4 1 5 of RCC 07 Page 69 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document R5 26 10 The requirements of user stories US5 9 and US5 10 shall be implemented locally on the device R5 26 11 For the requirements in user story US5 11 the client shall support the following procedure e Itis the responsibility of the Messaging Server to deliver messages in the correct order so the Client can rely on it when sorting messages The client shall interleave the sent and received messages in
250. t conversation session as soon as the user tries to access the service associated with those events on that device or interface i e all previously unsynchronised events for all conversations shall be downloaded as soon as a user opens the messaging app on an inactive device OM If a period of inactivity controlled by the device is reached for a conversation session then that session will be terminated Any further messages events and or content sent to the user within that conversation shall be delivered again to all the user s registered devices interfaces until a new session is established when the conversation is accepted on one of these devices or interfaces Inactivity means no messages or notifications sent and received from that device interface in the active session OM When an RCS user A Party transfers a file or File Transfer based event to another RCS user B Party who has multiple RCS enabled devices and the File Transfer is sent outside of an existing Chat conversation session the notification will arrive on all of the B Party s RCS enabled devices and or interfaces which are online OM When an RCS user A Party transfers a file or File Transfer based event to another RCS user B Party who has multiple RCS enabled devices and interfaces inside an existing conversation session then the preview icon or file shall arrive on the B Party s active device or interface depending on the Auto Accept setting i e O
251. t any time after successful first time registration R2 5 2 The display of that message shall be able to come with EITHER one OR two buttons to respond by the user R2 5 3 The operator shall be able to determine the button texts e g accept of that popup R2 5 4 The responses to the message shall be relayed back to the network V2 0 Page 17 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document R2 5 5 The presentation of the message shall be clear to the user and not hidden within the notification tray for action but be presented on top of the screen R2 5 6 Depending on the response by the user the network can send a trigger to deactivate the RCS services on the device i e RCS services shall not be available on the device the RCS client will become inactive and not visible on the device R2 5 7 n case the RCS services are deactivated an RCS set up entry point shall become visible in the device e g settings R2 5 8 Upon operator policies additional messages may be displayed to the user US2 6 Asan operator want to request additional information from my users during first time registration in order to fulfil specific security purposes R2 6 1 Upon operator discretion users can be requested to enter additional information during first time registration in order to fulfil specific security requirements set by the operator NOTE Details are cover
252. t of the Audio Message can be played directly from the Chat application upon user action as indicated by the File Disposition being set to render see section 3 11 4 2 2 of RCC 07 The maximum length of an Audio Message is controlled by the service provider via the MAX RRAM DURATION parameter defined in section A 1 16 of RCC 07 The default value of this parameter is 600 seconds 10 minutes 8 3 2 Requirements matching R8 4 1 Audio Messaging see requirement R2 2 1 shall be done as described in section 3 11 of RCC 07 R8 4 2 Requirement R8 1 1 relies on the RCS Capability Discovery feature as per Capability Discovery and Service Availability page 25 No specific Audio Messaging capability tag or service is added for this feature As Audio Messaging relies on the File Transfer mechanism support of Audio Messaging is derived from the support of the File Transfer capability refer to Table 33 of RCC 07 V2 0 Page 99 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document 8 3 2 1 V2 0 R8 4 3 R8 4 4 R8 4 5 R8 4 6 R8 4 7 R8 4 8 R8 4 9 R8 4 10 R8 4 11 R8 4 12 R8 4 13 R8 4 14 R8 4 15 As a file can be sent to one or more contacts requirement R8 1 2 is covered As Audio Messaging is based on the File Transfer mechanism as per RCC 07 section 3 5 it inherits from the File Transfer features e Store and forward
253. tandard Emoji Emoticons version 1 0 available from http www gsma com network2020 wp content uploads 2013 05 RCS joyn Blackbird Unicode Standard emoji emoticons v1 0 2 pdf Annex B Document Management B 1 Document History Version Date Brief Description of Change Approval Editor Authority Company 1 0 16 09 2014 New PRD RCC 61 PSMC Wad Owojori GSMA 2 0 03 03 2015 Maintenance update and GFRG Wad Owojori alignment with RCS 5 3 GSMA B 2 Other Information Type Description Document Owner RCS Global Functional Requirements Group Editor Company Wad Owojori GSMA It is our intention to provide a quality product for your use If you find any errors or omissions please contact us with your comments You may notify us at prd gsma com Your comments or suggestions amp questions are always welcome Page 166 of 166
254. tations are compatible through the co existence solutions RCC 07 Section 2 6 1 3 V2 0 R3 4 1 Requirements R3 1 1 and R3 1 2 shall follow TE1 or TE2 The rest of the requirements under R3 1 3 R3 1 4 and R3 1 5 shall be implemented locally on the device The available services for requirement R3 1 3 are voice calling operator messaging with RCS messaging being available if configured through corresponding configuration parameters R3 4 2 User Story US3 2 requirements are implemented locally on the device In order to realise R3 2 3 requires the service provider to deploy a OPTIONS AS as specified in 2 6 1 1 5 RCC 07 or Presence server as specified in 2 6 1 2 2 RCC 07 Page 30 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document R3 4 3 Requirement R3 3 1 shall follow TE1 or TE2 Requirement R3 3 2 requirement is implemented locally on the device R3 4 4 Service providers need to configure how RCS service entry points are displayed and made selectable as described in requirement R3 3 3 Configuration Description Parameter parameter usage VIDEO UX This parameter controls the visibility and Optional selectability of the UX service entry point for video Parameter 0 default value 0 The Video service entry point will be conditionally visible and conditionally selectable In the case when the capability exchange is successful the service entry point is
255. ted in regards to the Functional Requirements and includes technical specification references and details that may influence how certain functions behave creating an overall guide for OEMs and application developers e Chapter 2 covers discovery and activation e Chapter 3 covers capability discovery and service availability e Chapters 4 to 13 detail the 10 major Common Core services e Chapters 14 to 16 address Security Data Off and RCS Settings Each feature is structured into three parts a user story that shall explain the user s view of the feature the context and the benefit or the rationale why the feature makes sense The second part lists the requirement s which describe how the user story shall be delivered to match the expectations The final part is the technical implementation which maps to or explains how to use the supporting technical specification 1 1 2 Common Core client scope The Common Core can be delivered in two ways for users 1 Implemented natively within the device by the 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 it s desktop In most cases implementation of features is identical for both native and downloadabl
256. the interaction in a way that RCS use of the primary identity is enabled in a secure way after the set up process US14 3 As an operator want to ensure that traffic and content generated by an RCS identity is generated by that identity s true user R14 3 1 Second Party and Third Party applications shall inherit the identity of the stack therefore whilst API access may be controlled not addressed here no additional RCS authentication shall be required from second and third party applications R14 3 2 All traffic generated by an identity shall be identifiable as such 14 3 Technical Information The technical implementation of RCS involves a number of technologies on the user network interface Encryption user authentication and access authorization is applied by the client and the network on a per protocol basis e g SIP HTTP IMAP The level of security for the individual technologies depend on the selection of the mean of authentication applied in the technical specification 14 3 1 User Authentication The following main user authentication and methods are used in RCS R14 4 1 User Authentication via the UICC based Authentication and Key Agreement protocol AKA This authentication protocol comes with a high level of security based on shared secrets exchanged between the UICC and the network authentication centre As a result of the initial authentication session keys are agreed which are used to secure the UNI signalling flow
257. the CHAT MESSAGING TECHNOLOGY configuration parameter defined in section A 1 4 3 of RCC 07 RCC 07 RCS 5 2 allows service providers to implement the file transfer user experience based on File Transfer over MSRP or File Transfer over HTTP The technology used for the transfer of a file to a Group depends on the support of File Transfer technologies of the conference focus The client shall select the technology as defined in sections 3 5 4 2 and 3 5 4 8 1 of RCC 07 If the conference focus does not support File Transfer the client may apply the alternative procedure defined in section 3 4 2 3 of RCC 07 A more detailed overview of applicable sections of the baseline specification will be provided once the detailed use case analyses identifies the required feature set 6 3 2 Technical Implementation of User Stories and Service requirements R6 37 1 For use case US6 1 the following definitions apply e The Group Chat service shall be offered to the user if the device configuration authorizes the service via the CHAT AUTH GROUP CHAT AUTH and CONF FCTY URI parameters defined in section A 1 4 of RCC 07 e The procedures for initiation of a group chat and the conditions for the client to select capable contacts are defined in section 3 4 4 of RCC 07 The service provider is able to determine for the client which contacts are capable for a group chat i e chat contacts only or any contact including non RCS contacts e The technical imple
258. the bearer session However attackers will be able to gain unauthorized access to the network services using a bearer session on behalf of the user User based Authentication via one time password OTP whereby the user is authenticated for a signalling transaction by using a token transfer over a channel with a secure identification or authentication context e g the short message service or a sign on to a web portal Based on the one time authentication a long term authentication context can be generated SSO to prevent the need for subsequent authentication transactions Depending on the usage scenario the OTP based authentication can be executed without user impact e g primary devices in non 3GPP access or with user impact additional non SIM devices The single token exchange via OTP is secure in itself However it is vulnerable to spoofing attacks to gain access to the token used to authenticate the access e g via initiation of the authentication by malware on behalf of the user and eavesdropping of the OTP transfer 14 3 2 Encryption The User Network Interface transactions should be always encrypted to prevent eavesdropping of the user s personal communication in the various access and transit networks RCS makes use of the common encryption protocols i e Transport Layer Security and Ipsec 14 3 3 Storage of Authentication and Identification Data The RCS client need to store for active RCS users authentication and identific
259. the call R11 10 1 Each user in an IP video call shall be able to stop and restart transmitting their own live video at any point during the call R11 10 2 lf both users stop sharing their camera views either an in call screen may be displayed clearly indicating how the user can share his camera again or the video call may drop US11 11 As users in an IP video call we want to mute and unmute the voice i e mute microphone at any point during the call without interrupting the call i e video is maintained during the call R11 11 1 Each user in an IP video call shall be able to mute and unmute its own live audio at any point during the call V2 0 Page 120 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document US11 12 As users in an IP video call when we rotate i e user A B our devices the correct video orientation is displayed based on the orientation of each device R11 12 1OM The device shall handle the different orientation permutations depending on how the device is rotated during an IP video call US11 13 As users in an IP video call we i e user A B want to toggle between front and rear camera without interruption when the device supports two cameras R11 13 1 The user shall be able to toggle the camera i e front back which is recording the transmitted IP video signal given the phone supports two cameras R11 13 2Given the phone support two c
260. the device via the PROVIDE RCS IP VOICE CALL configuration parameter defined in section A 1 13 of RCC 07 If IP V2 0 Page 160 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document Voice Call is disabled by the user the device shall behave with regard to the procedures in RCC 07 as it has been disabled by the service provider R16 16 5As a clarification to the requirements for user story US16 4 it shall be noted NOTE that the SMS STATUS REPORT to notify the sender of a successful delivery is sent by the Service Centre and not by the receiving device To prevent the SC to send SMS STATUS report the originating client shall not request an SMS STATUS REPORT when submitting a short message Thus the client configuration Shall allow the sending client to request or not request SMS STATUS REPORT for sent messages This is only relevant when the MessagingUX parameter is set to 1 R16 16 6 The configuration parameter defined in the requirements for user stories US16 NOTE 5 and US16 6 controls the retrieval behaviour immediate or deferred retrieval of the MMS user agent of the integrated messaging client This setting shall only be available when the MessagingUX parameter is set to 1 R16 16 7The requirements for user story US16 7 shall be implemented locally on the device R16 16 8lf generating notifications about messages being displayed is disabled in accorda
261. the process is taking longer than expected This screen shall contain a text box with the previously given MSISDN so that the user can amend it if necessary and a retry button final UI and text label up to operator s discretion R2 9 2 R2 9 3 R2 9 4 R2 9 5 The procedure in R2 9 1 can be attempted a maximum number of times according to the operator s definition It is Recommended to set the maximum number to 10 to be consistent with R2 1 5 Temporary unavailable Applies to internal errors during configuration provisioning or configuration server unreachable as specified in section 2 3 3 2 4 of RCC 07 specs The device shall reattempt provisioning at a later stage i e at the next device start up Permanently unavailable In case the operator does not want to provide RCS services to a particular subscription an operator defined error message shall be displayed and the provisioning process is stopped The user closes the MSISDN input field e g by mistake without providing any input The user shall be presented the MSISDN input field a maximum number of 3 times while being not provisioned under non cellular connection Further configuration attempts shall automatically start once the user connects to a cellular network Page 19 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document 2 2 6 Provisioning push US2 10 As an operator want to be able to
262. the receiving device a file type specific icon NOTE There shall be file type specific icons at minimum for standard RCS content types for Contact Card Audio Messaging and Geolocation Push or a generic icon R7 13 1 3Selection of the preview icon on the receiving device shall trigger the download of the full file to the user s device R7 13 1 4The user shall have the option to delete the thumbnail preview without downloading the content R7 13 2 In case Auto accept for File Transfer is set to on R7 13 2 1The user does not have to accept the download for each received File Transfer R7 13 2 2The file is automatically downloaded and can be accessed in the Chat Conversation R7 13 3 The Operator shall have the option to set the default value for File Transfer Auto Accept via the device provisioning process R7 13 4 The user shall have the option to select or deselect File Transfer Auto Accept R7 13 5 As a user want to have a visible notification about the status of received files R7 13 6 OM File Transfer shall support status notifications per individual file receiver device V2 0 Page 88 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document R7 13 6 1 n case of auto accept off Thumbnail preview received indication that a file is waiting for download trigger on a receiving network R7 13 6 2File Transfer in progress on receiving device
263. tial Official Document RCC 61 RCS Common Core 1 1 Service Description Document R16 1 4 Any download applications that have been installed on a device shall have own means to activate deactivate the application this may be provided by the application or the operating system of the device US16 2 As a user I want to set an RCS Chat Alias R16 2 1 The user shall have the option to customise the name label which is presented during RCS Communications to participants for whom the user is not in the contact list US16 3 As a user want to enable or disable IP Voice Calls R16 3 1 Users shall be allowed to activate deactivate the RCS IP Call using an appropriate switch R16 3 2 Default position shall be Activated R16 3 3 This user setting shall be visible only when RCS IP Call is activated by the MNO US16 4 For Integrated Messaging As a user want to switch on off SMS Delivery Notification R16 4 1 The user shall have the option to select or deselect automatically sending a Delivery Notification for SMS they receive in an Integrated Messaging scenario R16 4 2 The default setting shall be based on individual operator configuration US16 5 As a user want to enable or disable automatic MMS download in Integrated Messaging R16 5 1 The user shall have the option to enable or disable automatic MMS download in Integrated Messaging R16 5 2 The default setting shall be enabled US16 6 Integrated Messagin
264. tic type messagingUX Node lt x gt Ext An extension node for service provider specific parameters Clients that are not aware of any extensions in this sub tree e g because they are not service provider specific should not instantiate this tree V2 0 Page 56 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document Status Occurrence Format Min Access Types Optional ZeroOrOne node Get Table 20 UX MO sub tree addition Service Provider Extension Node e Values N A e Type property of the node is urn gsma mo gcc ux 1 0 Ext e Post reconfiguration actions The client should be reset and should perform the complete first time registration procedure following a reconfiguration e g OMA DM HTTP e Associated HTTP XML characteristic type Ext In addition the service provider needs to be able to control the switch over behaviour between messaging technologies as defined in the functional part by means of new configuration parameters The Common Core configuration parameters are defined as follows Configuration Description Parameter parameter usage DELIVERY This parameter controls the timeout for the reception of Optional TIMEOUT delivery reports for RCS messages and files after which Parameter the client shall initiate a capability discovery or inform the user as defined in the Operator Messaging User stories If the value is set to 0 thes
265. ting a session it is a requirement to perform a capability exchange as described in sections 2 6 and 2 7 of RCC 07 and covered in Capability Discovery and Service Availability page 25 A service shall not be initiated if not supported by both parties NOTE 2 There is one exception to be considered if the device is in a VoLTE call the availability of the upgrade to video call implemented through ViLTE as in PRD IR 94 shall rely on the contact header negotiation during the VoLTE call establishment SIP INVITE and response 12 3 2 Detailed requirements realisation R12 24 1 The realisation for requirements US12 1 R12 1 1 R12 1 2 and R12 1 3 is covered in section 12 3 e Note that RCS sharing services outside a voice call covered in sections 3 6 1 3 3 6 1 4 4 3 6 2 2 3 6 2 4 3 6 4 1 2 and 3 6 6 2 of RCC 07 are outside the scope and thus not applicable R12 24 2 n order to fulfil requirement R12 1 4 End User Notifications as described in section 2 10 of RCC 07 shall be used 12 3 2 1 Live Video R12 24 3 In order to fulfil requirements US12 2 R12 2 1 R12 2 2 R12 2 3 and R12 2 4 and to resolve the conflict between the video share and RCS IP video call service in case they are both available following capability exchange the following considerations shall be taken into account e lf the parameter RCS IP VIDEO CALL UPGRADE FROM CS as described in Annex A 1 13 of RCC 07 is set to 0 then video share shall prevail
266. tion 9 3 Overview For instance only the active device will receive the messages of the ongoing session There is no real time synchronization with the Common Message Store However it is up to the client to give the user the illusion that they are updated in a timely manner due to the guidelines defined in section 3 2 6 2 8 of RCC 07 Requirement R9 3 17 is covered by the synchronization guidelines defined in section 3 2 6 2 3 of RCC 07 Requirement R9 3 18 is covered as per section R9 5 4 Requirement R9 3 19 is covered as described in section R9 5 4 forking to all registered devices Disabling Auto accept is achieved by provisioning the FT AUT ACCEPT parameter to 0 see Table 86 in Section A 1 5 of RCC 07 A user may override the auto accept with a local setting This local setting will be valid regardless of the session state R9 5 28 1When using the FToHTTP technology the requirement R9 3 20 is covered by the procedures of section 3 5 4 8 3 1 of RCC 07 since there is already an established chat session it is required to reuse it to convey the File Transfer via HTTP message body content When receiving the File Transfer request the receiving device shall follow the rules of File Transfer incl Geolocation Push page 84 related to auto acceptance see FT AUT ACCEPT parameter in Table 86 of RCC 07 R9 5 28 2When using the FToMSRP technology the requirement R9 3 20 is currently not covered in the RCS s
267. to send the message until the first success response is received from the network The message may be in this state for some time when the user is NOT registered with the IMS core e g offline or airplane mode e Sent A first SIP provisional response is received from the network if the message is sent as part of the INVITE or a MSRP 200 OK is received in case the message was sent over MSRP e Delivered When receiving the Delivery Notification with status set to delivered e Displayed When receiving the Displayed Notification with the status set to displayed e Error When an error different from 486 487 is received Receipt of a 486 487 doesn t change the status of the message Notifications on delivery status information as defined in R5 2 2 shall be stored and forwarded in the store amp forward server as specified in section 3 3 4 1 5 RCC 07 For the requirements in user story US5 3 the device shall support the encoding and display of the graphical elements as defined in the referred Annexes The requirements in user story US5 4 shall be implemented locally on the device The indication that the other party is typing in requirement R5 5 1 is derived from the reception of the isComposing indication as defined in section 3 3 4 1 of RCC 07 It should be noted that the isComposing indication can only be transferred if an active chat session exist Clients should send the isComposing indication only if a chat se
268. ts in time Capability discovery can also be used by RCS entities to detect service awareness of other RCS users on behalf of an RCS service or user The availability of a RCS service is influenced by three categories of conditions 3 Provisioning status 4 Device capability and status 5 Network conditions 3 2 User Stories and Feature Requirements US3 1 As a user want to be aware of the ways can communicate with contacts stored in my contact list regardless of their service provider or country where they reside R3 1 1 The device shall make visible to the user whether a contact is RCS enabled and if so for which RCS services or categories they are capable and available for at a given point in time R3 1 2 The device shall make visible to the user about the detected RCS capabilities for contacts following a contact list scan or an individual contact capability check V2 0 Page 25 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document R3 1 3 R3 1 4 R3 1 5 The device shall only make visible services that are known to be compatible with defined RCS services for a Non RCS contact For integrated messaging as defined in Operator Messaging page 36 there shall not be any RCS service entry points when the recipient is known to be a non RCS user When more than one RCS feature can deliver the similar service the RCS capability and service availabil
269. tus Occurrence Format Min Access Types Required One node Get Table 7 UX MO sub tree addition node e Values N A e Type property of the node is urn gsma mo gcc ux 1 0 e Associated HTTP XML characteristic type UX Node lt x gt UX videoUX Leaf node that describes the visibility and selectability of the video UX service entry point If not instantiated the same UX service entry point shall be used V2 0 Page 33 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document Status Occurrence Format Min Access Types Required ZeroOrOne Bool Get Replace Table 8 UX MO sub tree addition parameters videoUX e Values 0 the Video service entry point will be conditionally visible and conditionally selectable 1 the Video service entry point will be conditionally visible and always selectable Post reconfiguration actions As the client remains unregistered during configuration there are no additional actions apart from de registering using the old configuration and registering back using the new parameter e Type property of the node is urn gsma mo gcc ux 1 0 videoUX e Associated HTTP XML characteristic type videoUX Node lt x gt UX incallUX Leaf node that describes the visibility and selectability of the UX service entry point s for In call services If not instantiated the same UX service entry point shall be used Status
270. uced to allow the user to see who set up the Group Chat see requirement R6 6 2 e IP Voice Call o Additional user story included to allow the user to see what the call bearer is in use for the call see requirements for user story US10 12 e Introduction of LED notifications for received one to one group chat and file transfer messages e Editorial clarifications to Audio Messaging and Messaging for Multi device sections NOTE Further improvements to the Messaging for Multi device section Such as introduction of synchronisation triggers are expected once the work of the Multi device Messaging Operator Interest Group has been concluded e Device Provisioning page 10 The ALLOW RCS EXTENSIONS parameter defined in Table 94 of RCC 07 indicates at a general level whether apps are allowed or not 14 Security against Malware 14 1 Description Authentication in RCS services on an individual device is currently done with a solution based on username password combination There is a risk that these credentials are hijacked by a malware application and used for spoofing identities There is a need to offer an enhanced security function at least temporarily until a long term solution is available 14 2 User Stories and Feature Requirements US14 1 As a user want to use my operator communication services safely and securely R14 1 1 OM RCS services shall use an authentication mechanism that is safe and secure not allowing 3 part
271. uirements for user story US5 13 e Group Chat o Additional requirement introduced to allow the user to see who set up the Group Chat see requirement R6 6 2 e IP Voice Call o Additional user story included to allow the user to see what the call bearer is in use for the call see requirements for user story US10 12 e Introduction of LED notifications for received one to one group chat and file transfer messages e Editorial clarifications to Audio Messaging and Messaging for Multi device sections NOTE Further improvements to the Messaging for Multi device section Such as introduction of synchronisation triggers are expected once the work of the Multi device Messaging Operator Interest Group has been concluded e Device Provisioning page 10 e Secondary devices or interfaces shall be provisioned as R2 11 3 page 20 e Configuration of secondary devices shall be done as described in section 2 3 3 4 of RCC 07 R9 5 2 Addressing and Routing V2 0 Page 107 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document e Each device or interface that is registered to the IMS is distinctly identified either via a GRUU or via a sip instance refer to sections 2 4 2 and 2 11 3 of RCC 07 R9 5 3 Capabilities handling e The capability discovery shall be performed as specified in section 2 6 of RCC 07 e A service provider allowing SIP OPTIONS for the Capability exchange
272. user shall not be given the option of selecting files that are not compatible with the MMS technology For files sent from the device using MMS the restrictions of the MMS service on file type and size will apply For MMS files sent from the device the user shall be notified of file format changes based on the MMS service parameters For 1 to 1 Chat messages the full RCS chat experience applies e g but not limited to emoticons and Emoji guaranteed correct display and Delivery and Display Notifications shall be available Details of the full RCS chat experience are described in 1 to 1 Chat page 61 SMS messages shall support emoticons according to the RCS standard It is accepted compromise that some emoticons may not be correctly converted to graphics by legacy receiving devices SMS messages shall support Emoji according to the RCS standard if UNICODE messaging encoding is available either via automatic or manual selection Whenever UNICODE encoding is not available it shall not be possible to send Emoji It is an accepted compromise that some Emoji may not be correctly converted to graphics by legacy receiving devices US4 5 As an operator want to make sure that any application taking on default management of xMS messaging on a device of an RCS enabled user shall also display and take on management of RCS messages and ensure that the operator promise of Operator Messaging is guaranteed V2 0 Page 3
273. vice initiation SIP INVITE sent to recipient R12 24 18 Requirement R12 19 1 shall be implemented locally in the device 12 3 2 3 Share any file during call R12 24 19 The realisation for requirements of user stories US12 20 R12 20 1 and R12 20 3 and US12 21 R12 21 1 and R12 21 2 are covered in section 12 3 share any file during a call NOTE It is required for a client device implementation to be able to identify whether V2 0 a File Transfer is received from the other party in a call to if so present the File Transfer within the call window instead the messaging application Page 135 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document If the conversation continues after the call is terminated it is expected that the exchange takes place within the messaging application meaning the exchanges that took place during the call are part of the messaging history R12 24 20 Requirement R12 20 2 and R12 20 6 shall be implemented locally in the device R12 24 21 For the requirements of user story US12 21 technical information of File Transfer incl Geolocation Push page 84 shall be considered In general section 3 5 of RCC 07 shall be considered R12 24 22 For requirement R12 21 2 file display options are the same as described in File Transfer incl Geolocation Push page 84 and are not different within an in Call context 12 3 2 4 Exchange
274. when attempting to establish a connection with a contact For In Call services a capability check shall always be made when the call has been set up and irrespective of whether the interval of capability checks has expired or not R3 3 7 8 Each response to a capability service availability request update shall include the current or most recently available capability availability information R3 3 7 9 A sender of a capability service availability request shall include the sender s own latest capability and availability information in that request R3 3 8 OM The operator shall be able to limit the impact of capability and availability checks network load device battery drain by implementation of a capability and availability server which buffers online and or offline capabilities and availability of RCS users and answers capability and availability checks R3 3 8 1 The operator may respond to capability requests with current user capabilities or service availabilities which are stored on the capability or service availability server Page 29 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document 3 3 3 3 1 R3 3 9 The RCS capability of a contact shall be removed when in the process of capability discovery and service availability exchange the network returns an error that indicates the user is not a provisioned RCS user R3 3 10 When a client is permanently r
275. y available on primary devices in case NO cellular coverage is given US10 5 As a service provider want the RCS IP Voice Call service not as an end to end service but only as coverage interface extension service breaking in out to standard CS VoLTE call connected legs R10 5 1 OM NNI for calls using RCS IP Voice Call on either leg even if both originating and terminating legs are RCS IP Voice Call shall be based on either the existing or to be built interface for CS and or VoLTE US10 6 Asa service provider want to configure one of the following options for RCS IP Voice Call on a primary device a No RCS IP Voice Call availability b RCS IP Voice Call is available when connected to Wi Fi without cellular reception R10 6 1 The MNO shall be able to activate or not activate the RCS IP Voice Call service using the provisioning process of a primary device R10 6 2 lf activated during the provisioning process primary cellular devices shall only support RCS IP Voice Call over a Wi Fi data bearer NOTE A RCS IP Voice call that is connected on a Wi Fi bearer shall remain connected as long as the Wi Fi bearer is available and the users decide to maintain the call US10 7 As a service provider want to configure one from the following options for RCS IP Voice Call on any secondary device a No RCS IP Voice Call support b RCS IP Voice Call is available on any access e g Wi Fi and cellular data R10 7 1 The MNO shall b
276. y applications to retrieve any user data including data that is relevant for authentication against networks R14 1 2 OM Authentication mechanism s shall be defined for a user on devices with a SIM R14 1 3 OM Authentication mechanism s shall be defined for a user on devices without a SIM V2 0 Page 144 of 166 GSM Association Non confidential Official Document RCC 61 RCS Common Core 1 1 Service Description Document R14 1 4 OM Devices containing a SIM which is associated with the user s RCS identity shall use any available SIM based authentication mechanism in preference of a non SIM based authentication mechanism R14 1 5 User interaction to ensure security solutions shall be minimized R14 1 6 lf manual user interaction is required this interaction shall be limited to a single one time experience and not be repeated in case but not limited to device re provisioning R14 1 7 lf manual user interaction is required for native implementations any user interaction shall be performed on one single screen or an intuitive flow of screens US14 2 As an operator want to customize the enhanced security function R14 2 1 The security solution shall offer the option for the operator to enable or disable the function with appropriate security control R14 2 1 1 Enable or disable over the air R14 2 1 2Enable or disable for selected devices R14 2 2 lf user interaction is required the user shall be guided to accomplish
277. y has not yet determined B Party s capabilities the proposed File Transfer Service shall be MMS and messages are queued locally and delivered as soon as cellular connectivity is restored NOTE This shall be the case even if B Party is a known RCS user R4 15 4 3lf after the A Party user has entered the file selection process B Party s capabilities for RCS File Transfer are received the proposed File Transfer Service shall be adjusted to RCS File Transfer if the change is visible to the user it can be manually changed back and if the user has not manually selected the Messaging Service in this Session previously NOTE Taking into consideration the exception detailed in R4 15 3 3 File Transfer 1 FT_HTTP_CAP_ALWAS _ ONZ 0 Selected File Transfer Service non cee CO to Cellular network sores weep User A Sender Connectto RCS si to RCS Connect to Cellular network wa va va User B Receiver RCS user __ ComnecttoRCS_ wa Connect to RCS Default FT service Pert seves gs Must Proposed Service User Choice Choice On device caching of unsent files required and user shall be informed Table 14 Table to explain and summarize static conditions and proposed Messaging Service by the device logic 4 2 6 Integrated Messaging File Transfer 2 FT_HTTP_CAP_ALWAYS_ON 1 File Transfer with Store and Forward US4 16 As a user want the best File Transfer Service to be proposed to me to convey my files R4 16 1 Th

RCS Common Core 1.1 Service Description Document

Contents

Download Pdf Manuals

Related Search

Related Contents