RCS e Advanced Comms Specification v1 1 Final

RCSe AdvancedCommunications
RCSeAdvancedCommunications: ServicesandClientSpecification Version1.1 April08,2011
RCSeAdvancedComms: Servicesandclientspecification
I.
Indexofcontents
I. Indexofcontents............................................................................................................2 II. Indexoffigures...............................................................................................................6 III. Indexoftables................................................................................................................8 IV. Documentchangelog ..................................................................................................10 . V. Acronymsandabbreviations........................................................................................11 VI. Normativereference....................................................................................................13 1. Introduction..................................................................................................................15 1.1 RCSePrinciples....................................................................................................16 1.2 OEMIntegration...................................................................................................17 1.3 Conformance........................................................................................................17 1.4 Scopeandfutureevolution..................................................................................18 2. Registrationandcapabilitiesdiscoveryprocess...........................................................19 2.1 Firsttimeregistrationandclientconfigurationprovisioning..............................19 2.1.1 RCSeclientconfigurationstorage...................................................................22 2.2 Registrationprocess.............................................................................................23 2.2.1 Additionalmessageauthentication..................................................................23 2.2.2 Registrationprocessandscenarios..................................................................24 2.2.2.1 Firsttimeregistration................................................................................24 2.2.2.1.1 Additionalfirsttimeconfigurationscenarios.....................................26 2.2.2.1.2 Autoconfigurationmechanisms.........................................................26 2.2.2.2 Registration ...............................................................................................30 . 2.2.2.3 Reregistration...........................................................................................32 2.2.2.4 Deregistration............................................................................................33 2.2.2.5 Registrationstatusandavailablecapabilities...........................................33 2.2.2.6 Registrationfrequencyoptimization.........................................................33 2.3 Capabilitydiscovery..............................................................................................33 2.3.1 CapabilitydiscoveryprocessthroughOPTIONSmessage................................34 2.3.1.1 SIPOPTIONSmessageextensiontosupportcapabilitydiscovery............35 2.3.1.2 Futureextensionstothemechanism........................................................37 2.3.1.3 SIPOPTIONSexchangeoptimisations.......................................................38 2.3.1.4 UIintegrationoptimisations......................................................................38 2.3.1.5 SIPOPTIONSandmultidevicesupport......................................................39 2.3.2 Capabilitydiscoveryviapresence ....................................................................40 . 2.3.2.1 EnhancingANONYMOUSSUBSCRIBEmechanismwithXDMSlists ..........41 . 2.4 Newuserdiscoverymechanism...........................................................................41 2.4.1 DiscoveryviaOPTIONSmessage......................................................................42 2.5 Capabilitypollingmechanism..............................................................................45 2.6 ManagementofsupplementaryRCSfunctionality..............................................49 2.7 RCSeandcapabilities..........................................................................................49 2.7.1 CapabilityExtensions........................................................................................51 2.7.2 IMstoreandforward .......................................................................................52 . 2.7.3 Videointeroperability.......................................................................................53 2.8 RCSeprotocols....................................................................................................53 Page 2 of151
RCSeAdvancedComms: Servicesandclientspecification 2.8.1 RTPandNATtraversal......................................................................................54 2.9 Addressingandidentities.....................................................................................56 2.9.1 Overview...........................................................................................................56 2.9.2 DeviceIncomingSIPRequest...........................................................................56 2.9.2.1 From/PAssertedIdentity..........................................................................56 2.9.3 DeviceOutgoingSIPRequest...........................................................................57 2.9.3.1 Identificationofthetargetcontact...........................................................57 2.9.3.2 SelfIdentificationtothenetworkandtheaddressedcontact:................57 2.9.3.3 Useralias...................................................................................................57 . 2.10 Datatrafficandroamingconsiderations .............................................................58 . 2.10.1 Dataconnectionnotifications............................................................................59 2.11 Privacyconsiderations..........................................................................................59 2.12 RCSeandLTE.......................................................................................................60 2.12.1 LTEandVoiceoverLTE...................................................................................60 2.12.2 LTEcapabilitydiscoveryusingtheRCSe........................................................60 2.12.3 LTEandVideosharefunctionality..................................................................61 2.13 EndUserConfirmationRequests.........................................................................61 2.13.1 ExampleUC1:Acceptingtermsandconditions.............................................64 2.13.2 ExampleUC2:AcceptingExtraCharges .........................................................65 . 2.14 GRUUandmultidevicesupport............................................................................66 3. RCSesequenceandUXdiagrams................................................................................67 3.1 AccesstoRCSeservicesthroughaddressbookorcallloginteraction ..............68 . 3.1.1 Generalassumptions........................................................................................68 3.1.2 Capabilitiesupdateprocess..............................................................................69 3.2 IM/chatservice.....................................................................................................71 3.2.1 Generalassumptions........................................................................................71 3.2.2 DeltabetweenRCSeandRCSRelease2ontheIMfunctionality...................71 3.2.2.1 FunctionalLevel.........................................................................................71 3.2.2.2 Technical/ProtocolLevel...........................................................................71 3.2.2.3 Deliverynotifications.................................................................................73 3.2.2.4 Displaynotifications..................................................................................74 3.2.3 Clientassumptions...........................................................................................74 3.2.4 1to1Chat........................................................................................................77 3.2.4.1 Initiatingachat..........................................................................................77 3.2.4.2 Answeringachat.......................................................................................78 3.2.4.3 Messagesexchangedinanestablishedchat.............................................78 3.2.4.4 Displayandlocalstorage...........................................................................78 3.2.4.5 Leavingthechatcomposingwindow........................................................78 3.2.4.6 IsComposingnotification........................................................................79 3.2.4.7 Closingachat/Reopeningachat............................................................79 3.2.4.8 Chatinactivitytimeout..............................................................................79 3.2.4.9 Chatabnormalinterruption......................................................................79 3.2.4.10 ReOpeningachat...................................................................................80 3.2.4.11 StoreandForwardMode........................................................................80 3.2.4.12 Multidevicehandling...............................................................................81 3.2.4.13 Switchingto1tomanyChat...................................................................81 3.2.4.14 Filetransferwithin1to1chat................................................................82 Page 3 of151
RCSeAdvancedComms: Servicesandclientspecification 3.2.4.15 Otherfeatures.........................................................................................82 3.2.4.16 Protocolflowdiagrams ...........................................................................82 . 3.2.4.16.1 Generalonetoonechat..................................................................82 3.2.4.16.2 StoreandForward............................................................................85 3.2.4.16.3 Multidevice.......................................................................................85 3.2.4.16.4 Leavingaonetoonechat................................................................85 3.2.4.16.5 Onetoonechatforcedtermination................................................87 3.2.4.16.6 Exchangecapabilitiesduringa1to1chat.......................................88 3.2.5 1tomanyChat.................................................................................................89 3.2.5.1 Initiatingachat..........................................................................................89 3.2.5.2 GeneralBehaviour.....................................................................................90 3.2.5.3 Closingmultichat.......................................................................................90 3.2.5.4 Protocolflowdiagrams..............................................................................90 3.2.5.4.1 StartamultipleIMsessionfromtheIMcompositionwindow..........90 3.2.5.4.2 GetparticipantsofmultichatIMsession...........................................92 3.2.5.4.3 StartagroupchatsessionfromaIM/chatapplication......................93 3.2.5.4.4 AddaparticipanttoanalreadyestablishedonetomanyIMsession94 3.2.5.4.5 SendingaIMmessagefromtheIMmultiplesessionwindow ..........95 . 3.2.5.4.6 UserinamultipleIMsessiongoesoffline .........................................96 . 3.2.5.4.7 LeavingaIMmultiplesession ............................................................97 . 3.3 RCSeservicesduringacall..................................................................................98 3.3.1 Generalassumptions........................................................................................98 3.3.2 Exchangecapabilitiesduringacall.................................................................100 3.3.3 Sharevideoduringacall ................................................................................101 . 3.3.4 Stopsharingvideo(RTP)duringacall:Senderinitiated................................102 3.3.5 Stopsharingvideo(RTP)duringacall:Receiverinitiated..............................103 3.3.6 Stopsharingvideo(RTP)duringacallbecausetherequiredcapabilityisno longeravailable..........................................................................................................104 3.3.7 Sharepicturesduringacall............................................................................105 3.3.8 Stopsharingapictureduringacall:Senderinitiated....................................106 3.3.9 Stopsharingapictureduringacall:Receiverinitiated..................................107 3.3.10 Stopsharingapictureduringacallbecausetherequiredcapabilityisno longeravailable..........................................................................................................108 3.3.11 Declinesharevideoorpictureduringacall.................................................110 3.3.12 Nongracefultermination(sender):Videoorpicturesharing.....................111 3.3.13 Nongracefultermination(receiver):Videoorpicturesharing...................112 3.3.14 Multipartycallandimage/videoshare........................................................115 3.3.15 Callonholdandimage/videoshare.............................................................116 3.3.16 Waitingcallandimage/videoshare.............................................................117 3.3.17 Callsfromprivatenumbers..........................................................................117 3.4 Filetransfer.........................................................................................................118 3.4.1 Generalassumptions......................................................................................120 3.4.2 Selectingthefiletransferrecipient(s)............................................................120 3.4.3 Standardfileshareprocedure........................................................................122 3.4.4 Fileshareerrorcases......................................................................................123 3.4.5 Fileshareandfiletypes..................................................................................124 3.4.6 Filesizeconsiderations...................................................................................124 Page 4 of151
RCSeAdvancedComms: Servicesandclientspecification A. ANNEXA:Extensionstothedatamodel....................................................................125 A.1 Managementobjectsparameteradditions.......................................................125 A.1.1 Presencerelatedconfiguration......................................................................125 A.1.2 XDMrelatedconfiguration.............................................................................125 A.1.3 IMrelatedconfiguration................................................................................125 A.1.4 Filetransferrelatedconfiguration.................................................................127 A.1.5 IMSCore/SIPrelatedconfiguration..............................................................127 . A.1.6 ConfigurationrelatedwithAddressbookBackup/Restore..........................127 A.1.7 Configurationrelatedwithsecondarydeviceintroduction...........................127 A.1.8 Capabilitydiscoveryrelatedconfiguration....................................................128 A.1.9 APNconfiguration..........................................................................................129 A.1.10 Enduserconfirmationparameters..............................................................129 A.2 RCSManagementtreesadditions......................................................................129 A.2.1 IMSsubtreeadditions...................................................................................129 A.2.2 Presencesubtreeadditions...........................................................................130 A.2.3 XDMSsubtreeadditions................................................................................132 A.2.4 IMMOsubtreeaddition................................................................................133 A.2.5 CapabilitydiscoveryMOsubtree..................................................................135 A.2.6 APNconfigurationMOsubtree.....................................................................137 A.2.7 OtherRCSeconfigurationsubtree...............................................................138 A.3 OMACPspecificconfigurationandbehaviour..................................................140 A.3.1 OMACPconfigurationXMLstructure...........................................................140 . B. ANNEXB:IMStoreandforwarddiagrams.................................................................141 B.1 IMwithoutstoreandforward............................................................................141 B.2 Storeandforward:Receiveroffline...................................................................142 B.3 Storeandforward:MessagedeferreddeliverywithsenderstillonanactiveIM session143 B.4 Storeandforward:Messagedeferreddeliverywithsenderonline..................144 B.5 Storeandforward:Messagedeferreddeliverywithsenderoffline..................145 B.6 Storeandforward:Notificationsdeferreddelivery...........................................146 B.7 Storeandforward:Notes...................................................................................147 C. ANNEXC:RCSeIM/Chatandmultidevice.................................................................148 C.1 Deliverypriortoacceptance..............................................................................148 C.2 Postacceptancebehaviour................................................................................149 C.3 RCSeIM/Chatandmultidevice:Notes..............................................................150 D. ANNEXD:Authors......................................................................................................151
Page 5 of151
II.
Indexoffigures
Figure1.RCSepositioning...................................................................................................15 Figure2.RCSeIndustryPropositionextendingthecommunicationsstack...................16 Figure3.RCSecapabilitydiscovery.....................................................................................16 Figure4.Firsttimeregistrationsequencediagram.............................................................25 Figure5.RCSealternativeconfiguration:Initialrequest....................................................27 Figure6.RCSealternativeconfiguration:Serverresponse................................................28 Figure7.RegistrationfromofflineoverPS(assumingSSO/GIBA).......................................30 Figure8.RegistrationfromofflineoverWiFiorPSnetworkswithoutSSO/GIBA authenticationsupport........................................................................................................31 Figure9.XCAPexchangeswhenusingdigestauthentication..............................................32 Figure10.Reregistration.....................................................................................................32 Figure11.Deregistration......................................................................................................33 Figure12.CapabilitiesdiscoveryviaSIPOPTIONSmessage................................................35 Figure13.CapabilitiesdiscoveryviaPRESENCE...................................................................41 Figure14.Adding/Editingacontact.....................................................................................44 Figure15.UpdatingtheXDMSlistofcontactssupportingsocialinformationviapresence functionality.........................................................................................................................45 Figure16.CapabilitiespollingviaOPTIONSmessage..........................................................46 Figure17.Capabilitiespollingviaanonymousfetch............................................................47 Figure18.RCSecapabilityandnewuserdiscoverymechanisms......................................48 Figure19.RTPsymmetricmediapathestablishment.........................................................55 Figure20.TermsandConditionUCexample.......................................................................64 Figure21.ExtraChargeUCexample....................................................................................65 Figure22.Addressbook:Capabilitiesupdate......................................................................69 Figure23.Addressbook:Capabilitiesupdate(II)................................................................70 Figure24.ReferenceUXforaccessingchatfromaddressbook/calllog ............................75 . Figure25.ReferenceUXforstartingachatfromtheIM/chatapplication.........................76 Figure26.ReferenceUXforstartingchatfromtheIM/chatapplicationhistory................76 Figure27.ReferenceUXfiletransferonthereceiverside..................................................77 Figure28.Onetoonechat..................................................................................................83 Figure29.OnetoonechatbackupmechanismtosendSMS.............................................84 Figure30.Leavingaonetoonechatsession(chatterminated)........................................85 Figure31.Leavingaonetoonechatsession(leavingchatinthebackground).................86 Figure32.Onetoonechatforcedtermination..................................................................87 Figure33.Capabilitiesexchangeduringachatsession.......................................................88 Figure34.Multichatsessioninitiation.................................................................................91 Figure35.Multichatsessioninitiation(II):Getparticipants................................................92 Figure36.StartagroupchatfromtheIM/chatapplication................................................93 Figure37.Addingnewuserstoamultichatsession...........................................................94 Figure38.Chatmessagesequenceonamultichatsession................................................95 Figure39.Forcedchatterminationinamultichatsession ................................................96 . Figure40.Leavingamultichatsession...............................................................................97 Figure41.Capabilitiesexchangeduringacall...................................................................100 Page 6 of151
RCSeAdvancedComms: Servicesandclientspecification Figure42.Sharevideoduringacall...................................................................................101 Figure43.Senderstopssharingvideoduringacall...........................................................102 Figure44.Receiverwantsnolongertoreceivevideoduringacall..................................103 . Figure45.Videocannolongerbesharedduringacall(capabilitynotavailable)............104 Figure46.Sharingapictureduringacall...........................................................................105 Figure47.Senderstopssharingapictureduringacall.....................................................106 Figure48.Receiverstopspicturesharing..........................................................................107 Figure49.Apicturecannolongerbesharedduringacall(capabilitynotavailable).......109 Figure50.Userdeclinessharingapictureduringacall.....................................................110 Figure51.Nongracefultermination(sender)forvideo....................................................111 Figure52.Nongracefulterminationofvideoorpicturesharingduringacall.................113 Figure53.Nongracefulterminationofvideosharingduringacall..................................114 Figure54.ReferenceUXforaccessingfilesharefromaddressbook/calllog...................118 Figure55.ReferenceUXforaccessingfilesharefrommediagalleryorfilebrowser.......118 Figure56.ReferenceUXforaccessingfilesharefromaIMwindow................................119 Figure57.ReferenceUXforfiletransferonthereceiverside..........................................119 Figure58.Selectinguserswhensharingafilefromthemediagallery/filebrowser........121 Figure59.StandardfiletransfersequencediagramSuccessfultransfer .......................122 . Figure60.StandardfiletransfersequencediagramReceiverrejectsthetransfer........123 Figure61.RCSeadditionstothepresenceMOsubtree..................................................130 Figure62.RCSeadditionstotheIMMOsubtree............................................................133 Figure63.RCSeadditions,capabilitysubtree..................................................................135 Figure64.RCSeadditions,roamingsubtree....................................................................137 Figure65.RCSeadditions,othersubtree........................................................................139 . Figure66.Standardchatwithoutstoreandforward........................................................141 Figure67.IMflowwithoutstoreandforward*................................................................141 Figure68.Storeandforward:Receiveroffline*................................................................142 Figure69.Storeandforward:Message(s)differeddeliverywithasenderstillonanMSRP session*..............................................................................................................................143 Figure70.Storeandforward:Message(s)differeddeliverywithasenderonline*.........144 Figure71.Storeandforward:Message(s)differeddeliverywithasenderoffline...........145 Figure72.Storeandforward:Notification(s)differeddelivery* ......................................146 . Figure73.IMandmultidevice:Deliverypriortoacceptance*..........................................148 Figure74.IMandmultidevice:Postacceptancebehaviour* ...........................................149 .
Page 7 of151
III.
Indexoftables
Table1.Documentchangelog.............................................................................................10 Table2.Abbreviationsandacronyms..................................................................................12 Table3.Normativereference..............................................................................................14 Table4.SummaryofIMSregistrationrelatedconfigurationparameters...........................20 Table5.SummaryofRCSeclientconfigurationparameters..............................................22 Table6.RCSealternativeconfigurationemptyXML(noconfigurationchangesrequired)28 Table7.RCSealternativeconfigurationemptyXML(resetRCSeclient)...........................29 Table8.RCSealternativeconfigurationXMLstructurebasedonOMACP.......................29 Table9.StandardRCSRelease2SIPOPTIONStags.............................................................36 Table10.AdditionaltagstocovertheremainingRCSeservices........................................36 Table11.CompleteSIPOPTIONStagproposalforRCSe....................................................37 Table12.SIPOPTIONStagproposalforfuturelinesofwork..............................................38 Table13.RCSeservicesHWanddatabearerrequirements..............................................50 Table14.Storeandforwardpossiblescenarios..................................................................52 Table15.RCSerecommendedprotocols............................................................................54 Table16.APNconfigurationproposalfordatatrafficandroaming ...................................58 . Table17.Dataconnectionnotificationoptions...................................................................59 Table18.SIPOPTIONStagproposalforLTE........................................................................60 Table19.EndUserConfirmationRequestXSD....................................................................62 Table20.EndUserConfirmationResponseXSD .................................................................63 . Table21.EndUserConfirmationAcknowledgementXSD...................................................63 Table22.RCSeadditionalpresencerelatedconfigurationparameters...........................125 Table23.RCSeadditionalIMrelatedconfigurationparameters.....................................126 Table24.RCSeadditionalfiletransferrelatedconfigurationparameters.......................127 Table25.RCSeadditionalcapabilitydiscoveryrelatedconfigurationparameters..........128 Table26.RCSeroamingconfigurationparameters..........................................................129 Table27.RCSeenduserconfirmationparameters..........................................................129 Table28.IMSsubtreeassociatedOMACPconfigurationXMLstructure........................130 Table29.PresencesubtreeassociatedOMACPconfigurationXMLstructure................131 Table30.PresenceMOsubtreeadditionpresencenode.................................................131 Table31.PresenceMOsubtreeadditionparameters(usePresence)..............................132 Table32.CapabilityMOsubtreeadditionparameters(presencePrfl).............................132 Table33.XDMSsubtreeassociatedOMACPconfigurationXMLstructure.....................132 Table34.IMsubtreeassociatedOMACPconfigurationXMLstructure..........................133 Table35.IMMOsubtreeadditionIMnode .....................................................................133 . Table36.IMMOsubtreeadditionparameters(imConfFacURI)......................................134 Table37.IMMOsubtreeadditionparameters(imCapAlwaysOn)...................................134 Table38.IMMOsubtreeadditionparameters(imWarnSF)............................................134 Table39.IMMOsubtreeadditionparameters(ftWarnSize)...........................................135 Table40.CapabilitysubtreeassociatedOMACPconfigurationXMLstructure..............135 . Table41.CapabilityMOsubtreeadditioncapabilitydiscoverynode..............................136 Table42.CapabilityMOsubtreeadditionparameters(pollingPeriod)............................136 Table43.CapabilityMOsubtreeadditionparameters(capInfoExpiry)...........................136 Page 8 of151
RCSeAdvancedComms: Servicesandclientspecification Table44.CapabilityMOsubtreeadditionparameters(presenceDisc)............................137 Table45.APNsubtreeassociatedOMACPconfigurationXMLstructure........................137 Table46.APNMOsubtreeadditioncapabilitydiscoverynode .......................................137 . Table47.RoamingMOsubtreeadditionparameters(rcseOnlyAPN)..............................138 Table48.RoamingMOsubtreeadditionparameters(enableRcseSwitch)......................138 Table49.OthersubtreeassociatedOMACPconfigurationXMLstructure.....................139 Table50.OtherMOsubtreeadditioncapabilitydiscoverynode.....................................139 Table51.OtherMOsubtreeadditionparameters(endUserConfReqId).........................139 Table52.RCSeOMACPconfigurationXMLstructure .....................................................140 . Table53.CompleteRCSeOMACPconfigurationXMLstructure.....................................140
Page 9 of151
IV.
Documentchangelog
Version 1.0 Date Comments 12/02/2011 VersionreadyforreleasetoGSMA VersionreadyforreleasetoGSMA.Thisisadraft versionpublishedforgeneralreview. 11/03/2011 Pleasenotethefinal1.1versionwillnotcontain major functionality additions or changes of the existingonecomparedtothisdraft. VersionreadyforreleasetoGSMAincorporating the comments received on the previous draft. Thisversionisagainpublishedforgeneralreview. 23/03/2011 Pleasenotethefinal1.1versionwillnotcontain major functionality additions or changes of the existingonecomparedtothisdraft. 06/04/2011 VersionreadyforreleasetoGSMA
Table1.Documentchangelog
1.1finaldraft1
1.1finaldraft2
1.1
Page 10 of151
V.
Acronymsandabbreviations
Description SecondgenerationofGlobalSystemforMobileCommunications(GSM) Applicationserver Advancedvideocodec Circuitswitched DynamicHostConfigurationProtocol Dualtransfermode FullyQualifiedDomainName GPRSIMSBundledAuthentication GSMAssociation highdefinitionvoice Instant messaging. The term chat is also applied in this document to the sameconcept. IMapplicationserver InstantMessageDispositionNotification InternationalMobileStationEquipmentIdentity IMSAuthenticationandKeyAgreement InternetProtocol Longtermevolution Mobilenetworkoperator MobileSubscriberIntegratedServicesDigitalNetworkNumber MessageSessionRelayProtocol NetworkAddressTranslation OriginalEquipmentManufacturer Orthogonalfrequencydivisionmultiplex OMAClientProvisioning OMADeviceManagement ProtocolConfigurationOptions ProxyCallSessionControlFunction PacketDataProtocol Packetswitched RichCommunicationSuite RealTimeTransportProtocol SessionDescriptionProtocol SessionInitiationProtocol Shortmessageservice Singlesignon(typeofIMSauthentication) TransmissionControlProtocol TransportLayerSecurity UserDatagramProtocol UniformResourceIdentifier Page 11 of151
Term 2G AS AVC CS DHCP DTM FQDN GIBA GSMA HD IM IMAS IMDN IMEI IMSAKA IP LTE MNO MSISDN MSRP NAT OEM OFDM OMACP OMADM PCO PCSCF PDP PS RCS RTP SDP SIP SMS SSO TCP TLS UDP URI
RCSeAdvancedComms: Servicesandclientspecification VoLTE WiFi XCAP XDM XDMS XML VoiceoverLTE SynonymforWLAN,WirelessLocalAreaNetwork XMLConfigurationAccessProtocol XMLDocumentManagement XMLDocumentManagementServer ExtensibleMarkupLanguage
Table2.Abbreviationsandacronyms
Page 12 of151
VI.

Normativereference
Name Documentreference
3GPPTS24.1673rdGenerationPartnershipProject; [3GPPTS24.167] TechnicalSpecificationGroupCoreNetworkand Terminals;3GPPIMSManagementObject(MO) 3GPPTS24.2293rdGenerationPartnership IPmultimediacallcontrolprotocolbasedonSession [3GPPTS24.229] InitiationProtocol(SIP)andSessionDescription Protocol(SDP) [IETFDRAFTSIPCOREKEEP12] IETFSIPCorekeepIETFdraftversion12 [IETFDRAFTSIMPLEMSRP IETFSimpleMSRPseesmatchdraftversion SESSMATCH10] GSMAPRDIR.92IMSProfileforVoiceandSMS1.0 [PRDIR.92] 18March2010 RichCommunicationSuiteRelease1Functional [RCS1FUNDESC] DescriptionVersion2.0 14February2011 RichCommunicationSuiteRelease1Technical [RCS1TECREAL] RealizationVersion2.0 14February2011 RichCommunicationSuiteRelease2Functional [RCS2FUNDESC] DescriptionVersion2.0 14February2011 RichCommunicationSuiteRelease2Management [RCS2MO] ObjectsVersion2.0 14February2011 RichCommunicationSuiteRelease2Technical [RCS2TECREAL] Realization2.0 14February2011 RichCommunicationSuiteRelease2Endorsementof [RCS2OMASIMPLEENDORS] OMASIP/SIMPLEIM1.0Version2.0 14February2011 GSMARCSRelease4Endorsementof[PDRIR92] [RCS4IR92ENDORS] 14February2011 [RFC3261] SIP(SessionInitiationProtocol)IETFRFC TheSecureRealtimeTransportProtocol(SRTP)IETF [RFC3711] RFC [RFC3966] TheTELURIforTelephoneNumbersIETFRFC TheSessionTimersintheSessionInitiationProtocol [RFC4028] (SIP)IETFRFC TheUniversallyUniqueIDentifier(UUID)URN [RFC4122] NamespaceIETFRFC Page 13 of151
RCSeAdvancedComms: Servicesandclientspecification [RFC4961] [RFC5438] [RFC5626] [RFC5627] [RFC6135] [TS24.229] SymmetricRTP/RTPControlProtocol(RTCP)IETFRFC InstantMessageDispositionNotification(IMDN)IETF RFC ManagingClientInitiatedConnectionsintheSession InitiationProtocol(SIP)IETFRFC UsingGloballyRoutableUserAgentURIs(GRUUs)in theSessionInitiationProtocol(SIP)IETFRFC AlternativeConnectionModelfortheMessageSession RelayProtocol(MSRP)IETFRFC 3GPPTS24.229:IPmultimediacallcontrolprotocol basedonSessionInitiationProtocol(SIP)andSession DescriptionProtocol(SDP);Stage3
Table3.Normativereference
Page 14 of151
1. Introduction
The purpose of this document is to provide the detailed specifications that shall complement the current RCS Release 2 specification in order to set the initial reference implementationoftheRCSeservices. This initial implementation has been named RCSe Advanced Communications as it focusesonthecommunicationsserviceaspectsoftheGSMARCSRelease2specification. Buildingonestablishedinteroperabilityprincipleswithinthemobileoperatorecosystem, thisspecificationprovidesfurtheroptimisationoftheRCSRelease2specificationinorder to accelerate time to market and simplify the customer proposition, Figure 1. This renewedfocusisbasedonresultsfromcustomertrialstodateandabetterunderstanding ofwhereoperatorscanfurtherenhancetheirdatanetworkofferingtodelivermorevalue tocustomersandcomplementestablished3rdpartyservices. Thecurrentdocumentdoesnotdetailthesocialinformationviapresence1functionality describedintheRCSRelease2specification.However,anoperatorcandecidetolaunch RCSeserviceincludingboththeRCSsocialpresenceinformationdefinedinRCSRelease2 specificationinadditiontotheadvancedcommunicationsservicesdefinedinthepresent document. Both parts shall coexist within a device implementation if requested by an operator.
Not part of the RCS-e compliance
RCS Release 2 Specification Social profile information
RCS-e reference implementation
Communication Services information
Picture (Portrait) Icon Status text (Free text) Availability
IM/Chat File transfer Image share Video share
Discoverable & Interoperable

To be incorporated into the standard
Additional technical specifications contained in this document
RCS-e is a simple interoperable service extension to voice & text today
Figure1.RCSepositioning
Asaheadline,RCSeprovidesasimpleinteroperableextensiontovoiceandtexttoday. Theservicesaredesignedtorunoverdataandcanstandalone(e.g.Ishareapicturefrom themediagallery)orusedincombinationwithvoice(e.g.seewhatIseevideo).
BythistermwearereferringtothesetoffunctionalitiesdefinedintheRCSRelease1and2specifications andpresentedin[RCS1FUNDESC]insectionsfrom2.1.2to2.1.6.
Page 15 of151
FutureRCSeservices Imageandvideoshare(+voice) Filetransfer(+IM/chat)
Figure2.RCSeIndustryPropositionextendingthecommunicationsstack
1.1 RCS-e Principles

The fundamental mechanism that enables RCSe is service or capability discovery. For example,whenauser,UserA,scrollsthrough his/herAddressBookandselectsaRCSe contact,theclientperformsaninstantservicecapabilitycheck,beingabletodisplaythe serviceswhichareavailabletocommunicate. This mechanism is implemented using SIP OPTIONS. SIP OPTIONS is a peertopeer requestroutedbythenetworkthatwillgenerateoneof2typesofresponse: 1) The contact is registered for service and thecontacts service capabilities, at this pointintime,arereceivedandloggedbyUserA,or, 2) The contact is either not registered (they are provisioned but not registered) or NotFound(theyarenotprovisionedforservice). ThisdiscoverymechanismisimportantinthatitallowsUserAtodeterminewhatservices areavailablebeforetheyarecalledandallowsoperatorstorolloutnewagreedservices totheirownschedule.RCSethereforeprovidesanadaptiveframeworkfornewservice deployment. RCSe implementation allows operators to also use SIP OPTIONS as the preferred mechanism to initially discover (and/or periodically check) the service capabilities of all thecontactsofhis/heraddressbookwhenhe/shefirstregistersforservice.
ExtendingthecommsstackintheIPworld
IM/chat Messages(SMS/MMS) Voice

Figure3.RCSecapabilitydiscovery
CapabilitydiscoveryviaOPTIONS
Page 16 of151
1.2 OEM Integration

This specification is independent from any specific device operating system and is not intended to prescribe the supplier user experience. However, where appropriate key servicelogicisillustratedthroughwireframestoaidthereader.Itisfullyexpectedthat each handset supplier will map the basic service principles defined in this document withintheirownproductsanddriveinnovativeanddifferentiatedexperiences.
1.3 Conformance
The minimum conformance to the RCSe specification can be achieved by a terminal providing the necessary functionality to support both the capability and new user discovery based on SIP OPTIONS message (covered in detail in sections 2.3.1 and 2.4.1 respectively)plustheIM/chatfunctionality(coveredindetailinsection3.2). Therestofservicescoveredinthepresentspecificationareoptional,ensuringthatRCSe cantargetlowenddevicesand,therefore,boostthemarketpenetrationcurve. The terminal conformance to RCSe specification can be summarized in the following terms2: All the necessary procedures to provision and register with the core network elements(e.g.IMS,RCSAS,etc.)SHALL2besupported Capability/serviceandnewuserdiscoveryviaSIPOPTIONSandANONYMOUSfetch mechanism (covered in detail in sections 2.3.1, 2.3.2 and 2.4.1) SHALL2 be supported IM/chatfunctionality(coveredindetailinsection3.2)SHALL2besupported File transfer, image share and video share functionality (covered in detail in sections3.3and3.4)MAY2besupported. o The motivation behind making these services optional is to facilitate the penetrationofRCSeservicesinallthehandsettiersand,ultimately,aRCS ehandsetSHALL2trytosupportallthefeasibleRCSeservicestakinginto accounttherelevanthardwareandsoftwarelimitations. PleasenotethatinanycaseaMNOimplementingRCSeSHALL2providetheRCS filetransfer,imageshareandvideosharefunctionalityatnetworklevel. Pleasealsonotethatalthoughoutsidetheconformanceandconsistentlywithsection1.1, aRCSeterminalMAY2alsobesupplementedwiththesocialinformationviapresence 3 featuresasdefinedintheGSMARCSRelease2specifications.
PleasenotethetermsSHALLandMAYcontainedintheconformancesummaryareusedasdescribedin IETFRFC2119(http://www.apps.ietf.org/rfc/rfc2119.html) 3 BythistermwearereferringtothesetoffunctionalitiesdefinedintheRCSRelease1and2specifications andpresentedintheRCSRelease1FunctionalRealizationdocument(version1.1)insectionsfrom2.1.2to 2.1.6.
Page 17 of151
1.4 Scope and future evolution

This document establishes the core principles and services framework of RCSe through the initial, RCS Release 2 defined, set of functionality. However, the framework is designedtobeextensibleandsupportnewservicesgoingforward. Newservicesandfeatureswillinclude,butarenotlimitedto: RCSHomeServices(fixedline,PCandmobile) Additionalcapabilitiesandservices(e.g.HDvoice,advancedgeolocationservices, etc.) Enhancednetworkaddressbookservices Itisintendedtoensurebackwardcompatibilitywhenintroducingnew/extendedservices. Finally, it should be noted that the aim of the present document is to only specify functionality which can be validated in standard IMS/RCS Release 2 preproduction and production environments without any need for major customisation or changes apart fromthoseMNOsmayintroducetooptimiseordifferentiatetheirnetworks.
Page 18 of151
2. Registration and capabilities discovery process

2.1 First time registration and client configuration provisioning
The RCSe registration process can only take place once the client isconfigured and the user (uniquely identified by the relevant IMS identity [TELURI or SIPURI]) is correctly provisionedtoaccesstheRCSeservices. Inordertogivetheendusertheimpressionthatthenewservicesareworkingoutofthe boxandtominimisetheoperationalimpactonmobilenetworkoperators,bothprocesses areperformedautomatically. AmobilenetworkimplementingRCSeshouldbeabletodetectwhenauserattachesto the network with a RCSe capable handset for the first time. This event triggers two processes: Serviceprovisioning:Therelevantconfigurationisperformedinthenetworkto maketheRCSeservicesavailabletotheuser(e.g.provisioninganaccounton theIMScoreandrelevantapplicationservers). Clientconfiguration:Thenetworkpushestheclientconfigurationusingoneof the mechanisms described in section 2.2.2.1.2. The configuration document comprises a set of configuration parameters, some required to operate and otherstoconfiguretheclientbehaviour.
The minimum set of client settings is presented in the following tables: The first table coverstheparametersreferringtotheIMSregistrationwhilethesecondfocusesinRCSe specific parameters. Please note all the parameters described the configuration can be only modified by the MNO (via MNO customization settings or one of the procedures describedinsection2.2.2.1.2)anditisnotaccessibletotheterminaluser: Configuration parameter SIPproxy XDMserver TELURI SIPURI Comments PCSCFaddress(IP:portor FQDN:port) XDMSaddress(IP:port) UsersTELURI RCSeusage Mandatory Parameter Mandatoryparameter
(ItismandatoryandbecomesrelevantonlyifUSE PRESENCEissetto1)
Optionalparameter
UsersSIPURI
Mandatoryparameter4
When using GIBA, the temporary public identity used for IMS registration is built according to the proceduredefinedin3GPPTS24.229(itdoesnotrelyontheSIPURIandTELURIconfigurationparameters). OnlyoneoftheSIPURIorTELURIconfigurationparametermustbeconfigured.Theconfiguredparameter isusedtoselecttheURIwhichmustbeusedbytheRCSeclientduringnonREGISTERtransactions When using Digest, a SIPURI must be configured. This URI is used for REGISTER and nonREGISTER transactions.
Page 19 of151
RCSeAdvancedComms: Servicesandclientspecification SIP Foralternativedigest USER/PASSWORD authenticationtoSSO/GIBA Mandatory parameter
Table4.SummaryofIMSregistrationrelatedconfigurationparameters
Note1: Configuration parameters
Comments
RCSeusage
ThisistheparametercontainingtheURIfortheIM server. The parameter is optional and if not IM configured,meansthattheMNOisnotdeployingan CONFERENCE IMserver.ConsequentlyfeaturesrequiringIMserver FACTORYURI (i.e. 1tomany chat) will not be available for those customers. Thisparameterconfigurestheclienttosupportstore and forward when presenting the IM capability status for all the contacts. If set to 1, the IM capability for all RCSe contacts will be always IMCAP reported as available. Otherwise (0), the capability ALWAYSON willbereportedbasedonthealgorithmpresentedin section2.7. For example, this can be used in MNOs that are implementing the store and forward functionality forIM Incase,IMCAPALWAYSONissettoenabled(useof store and forward), anew parameter is used called IMWARNSFforUIpurposeonly. IMWARNSF If IM WARN SF parameter is set to (1) then, when chatting with contacts which are offline (Store and Forward), the UI must warn the user of the circumstance(e.g.messageonthescreen). Otherwise (0), there wont be any difference at UX level between chatting with an online or offline (StoreandForward)user. This is frequency in seconds to run a periodic capabilitiesupdateforallthecontactsinthephone address book whose capabilities are not available (e.g. nonRCSe users) or are expired (see CAPABILITYINFOEXPIRYparameter. Pleasenotethatifsetto0,thisperiodicupdateisno longerperformed.
Optional Parameter
Optional parameter
(ItismandatoryifIM CONFERENCEFACTORY URIisset)
Optional parameter
(ItismandatoryifIM CONFERENCEFACTORY URIissetandIMCAP ALWAYSONissetto1)
POLLING PERIOD
Mandatory parameter
Page 20 of151
RCSeAdvancedComms: Servicesandclientspecification WhenusingtheOPTIONSdiscoverymechanismand with the aim of minimizing the traffic, a timestamp willbekepttogetherwiththecapabilityinformation fetched using options. When performing a whole addressbook capability discovery (i.e. polling), an OPTIONSexchangetakesplaceonlyifthetimesince thelastcapabilityupdatetookplaceisgreaterthan thisexpirationparameter This parameter allows enabling or disabling the presencerelatedfeaturesonthedevice.Ifsetto0, presenceisdisabled,ifsetto1,presenceisenabled and the parameters related to presence defined in [RCS2_MO]apply. This parameter allows enabling or disabling the usageofcapabilitiesdiscoveryviapresence.Ifsetto 0,theusageofdiscoveryviapresenceisdisabled.If set to 1, the usage of discovery via presence is enabled.Thisparameterwillconsequentlyinfluence the inclusion of the associated tag to presence discoveryinOPTIONSexchanges. This parameter allows enabling or disabling the usageofthesocial information via presence.Ifsetto 0, the usage of the social information via presence featureisdisabled.Ifsetto1,thesocial information via presence feature is enabled. This parameter will consequently influence the inclusion of the associated tag to social information via presence in OPTIONSexchanges. As described in section 2.10, the user shall be able configuretoallowordisallowRCSeand/orinternet trafficinthehandsetsettings. If this parameter is set to 1, the setting is shown permanently. Otherwise it may (MNO decision) be onlyshownduringroaming. This is the reference/identifier to the APN configuration which should be used to provide PS connectivity ONLY to RCSe as described in section 2.10. ThisisafiletransfersizethresholdinKBtowarnthe userthatafilemayendupinsignificantcharges. Please note that if set to 0, the user will not be warned. ThisisafiletransfersizelimitinKB.Ifafileisbigger thanFTMAXSIZE,thetransferwillbeautomatically cancelled. Pleasenotethatifsetto0,thislimitwillnotapply.
CAPABILITY INFOEXPIRY
Optional parameter
(Itismandatoryif POLLINGPERIODissetto avaluegreaterthan0)
USEPRESENCE
Mandatory Parameter
PRESENCE DISCOVERY
Optional parameter
(Itismandatoryand becomesrelevantonlyif USEPRESENCEissetto1)
PRESENCE PROFILE
Optional parameter
(Itismandatoryand becomesrelevantonlyif USEPRESENCEissetto1)
ENABLERCSE SWITCH
Mandatory Parameter Mandatory Parameter Mandatory Parameter Mandatory Parameter
RCSEONLY APN FTWARNSIZE
FTMAXSIZE
Page 21 of151
RCSeAdvancedComms: Servicesandclientspecification ENDUSER CONFREQID This is identity used for sending the end user confirmationrequest.
Table5.SummaryofRCSeclientconfigurationparameters
Optional Parameter
Please note the detailed information on the extended managed objects for RCSe is coveredinANNEXA:Extensionstothedatamodel. Afterconfiguration,theclientisreadytoregisterwiththenetworkforthefirsttime.Once this registration is completed, the user is able to access the RCSe services. These configuration options could also be updated afterwards by the MNO by pushing new configurationdocumentusingOMADM. Finally,pleasenotethatwiththeaimofreducingthecomplexity,thePCSCFaddressused by the RCSe client is selected from the list in the IMS Management Object. The other autoconfiguration mechanisms (e.g. based on DHCP; based on the PCO info received duringPDPcontextactivation)areleftoutofthescopeofthisspecification.AnMNOmay request an OEM to implement such functionality as a customization, however, the validationofthisfunctionalitywillremainoutsideoftheRCSecompliance.
2.1.1 RCSeclientconfigurationstorage
TheRCSeand,toextend,theIMSconfigurationshouldbestoredsecurelyinthehandset andshouldnotbeaccessibletotheuserunlessexpressrequirementofaparticularMNO. ItshouldbenotedthatapreconditiontoprovideaccesstotheRCSefunctionalityshould bethatallthemandatoryparametersdescribedinsection2.1(Table5)mustbecorrectly configured. In the case any of the parameters is not configured or configured with an unexpectedvalue,theRCSefunctionalityshouldbedisabledandinanycasepresentedor accessibletotheuser(i.e.thephonebehavesasitwouldbeanonRCSeenabledphone). In this state, the RCSe functionality can be only restored by completing the firsttime registration procedure (see section 2.2.2.1; the firsttime registration includes the RCSe clientconfigurationusingoneoftheproceduresdescribedinsection2.2.2.1.2). If a RCSe configured device is reset, the RCSe client should securely back up the configuration in the device together with the associated IMSI prior to the reset. Please note that this also applies in the event of swapping SIM cards. The configuration associatedtotheoldSIMshouldalsobesecurelybackedupbeforetriggeringafirsttime registration. ThemotivationbehindtheRCSeconfigurationbackupistofacilitatethescenariowhere followingaresetorafteraSIMswap,theoriginalSIMcardisreintroducedinthedevice. Insteadtriggeringafirsttimeregistration,theRCSeconfigurationisrestored. Inthoseterminalswheretheprocessesmentionedinthepreviousparagraphs(reset,SIM card swap),the terminal also deletes the contacts (e.g. for example aparticular MNO is enforcing this sort of policy where a SIM swap causes the deletion of the contacts), the associatedRCSeinformation(i.e. cachedcapabilitiespercontactand RCSecontactlist) Page 22 of151
RCSeAdvancedComms: Servicesandclientspecification shouldbealsoremoved.Pleasenotethatinthiscase,theRCSeinformationassociatedto contactsisnotbackedup.
2.2 Registration process

The RCSe registration process uses the standard IMS registration procedure. The client sends a SIP REGISTER message to the network using the configuration parameters (SIP proxyaspresentedinTable4).Ifsupported,thenetworkshallauthenticatethemessage usingsinglesignon(SSO/GIBA)authentication. WhenSSO/GIBAauthenticationfails(e.g.theMNOequipmentdoesnotsupportitoritis not supported over WiFi), then digest authentication will be performed. This authenticationmechanismisbasedonachallengewhichthenetworksendstotheclient and which needs to be responded using the configured username/password pair (see Table4forreference). Please note that in the flow diagrams contained in this document which involve a registration,wehaveassumedthat: SSO/GIBAauthenticationtakesplacefirst Ifitfails(e.g.MNOnetworkequipmentdoesnotsupportit)digestauthentication isthentried
As part of the registration process, the network provides a validity period for the registration (SIP expire time). If the client is to remain registered after the registration validityperiodexpires,itmustregisteragain. Finallynotethatapreconditiontoregisteristhatallthemandatoryparameterspresented inTable4andTable5shouldbecorrectlyconfigured.InadditiontothisandifRCSeisthe onlyIMSbasedfunctionalityavailableonthephone(i.e.nootherIMSserviceslikeVoIP areincorporated),thepreconditionisextendedtoalsohaveallthemandatoryparameters presentedinTable5correctlyconfigured.
2.2.1 Additionalmessageauthentication
Depending on the network configuration, other SIP messages (apart from SIP REGISTER) mayalsorequireauthentication.Thereareseveralauthenticationmechanismsthatcanbe considered: SSO/GIBAauthentication(transparenttotheterminalasitishandledbytheMNO corenetwork) IMSAKAauthentication Digest(user/passwordauthentication)
For simplicity the present specification does only require terminals to implement digest authentication(requiredforsomeWiFiscenarios)andSSO/GIBA(duetothelowerimpact on the terminal/client side). An MNO may request to add additional authentication mechanisms as a customization, however this functionality is outside the scope of this specification and, consequently, the associated verification is outside the RCSe conformance. Page 23 of151
RCSeAdvancedComms: Servicesandclientspecification Itshouldbenotedthatinthefollowingsectionsdiagramsandwiththeaimofincreasing the readability, we have assumed that SSO/GIBA authentication is successful when accessingthroughthePSnetworkand,asmentionedbefore,digestauthenticationisused whenaccessingoveranonPSnetwork(i.e.WiFiscenarios). InadditiontotheSIPmessages,XCAPexchangesbetweentheclientandtheXDMSserver may also require authentication. For simplicity, mobile operator networks may use the sameusercredentialsandauthenticationmechanismforbothXCAPandSIPmessages.
2.2.2 Registrationprocessandscenarios
2.2.2.1 Firsttimeregistration TheassumptionsinthiscasearethatuserAhasbeenalreadyprovisionedtoaccessthe RCSeservices(e.g.thetariffincludestheservice)howeverhe/shehasneverusedaRCSe enabledphonebefore. Prior to the registration, it is necessary to provision the user on the network (known as auto provisioning) and to configure the client with the right settings. Once the auto provisioningandclientconfigurationhascompleted,thefirsttimeregistrationprocedure takesplace.Oncetheclientisprovisioned,thefirststepisregisterandtofindthesubset amongtheexistingcontacts(ifany)whoarealsoRCSeusers.
Page 24 of151
RCSeAdvancedComms: Servicesandclientspecification Phone Logic Client Logic MNOCore NW MNOIMSCore RCSAS

PS XDMS
AUTOPROVISIONINGANDCONFIGURATIONPROCESS
AttachestotheMNOnetwork The network detects the pair (MSISDN and IMEI), verifies that it is a RCS provisioned (i.e. tariff) user and that the IMEIisaRCSenabledphone ProvisionIMSandRCSASaccounts SendclientconfigurationviaOMADM/OMACP
SIPREGISTER
Restartre registration timer
SIP200OKexpiryvalue providedbytheIMSCore SIPPUBLISH(capabilities)
ONLYIFENABLEDVIA CONFIGURATION Thepublicationonly happensiftheUSE PRESENCEparameterisset 1(seeTable5)
OPTIONSmessage mechanism.We areassumingUser BisREGISTERED, UserCisNOT REGISTEREDand UserDisNOTan RCSeuser.UserC andDarenot addedtothelistof RCSeusers
SIP200OK
SIPOPTIONS(userB) SIP200OK(capabilitiesuserB) SIPOPTIONS(userC) ERROR480TEMPORARILYUNAVAILABLE/408REQUESTTIMEOUT SIPOPTIONS(userD) ERROR404NOTFOUND
Routed to/from userB
Startpollingtimer
Figure4.Firsttimeregistrationsequencediagram
Note that if the terminal is configured to handle presence related functionality (USE PRESENCE set 1 as presented in Table 5), this process will be used to identify those contactssupportingthesocialinformationviapresenceandthecapabilitydiscoveryvia presence functionalities. Additionally and provided the capability discovery via presence functionality is enabled (see PRESENCE DISCOVERY parameters in Table 5), the terminal
Page 25 of151
RCSeAdvancedComms: Servicesandclientspecification should also update the XDMS list of RCSe contacts supporting this functionality as presentedinFigure15. Inthepreviousdiagramwehavereferencedserviceprovisioningandconfiguration. When the handset is powered on, the network may be able to identify that the user/handset pair shall use RCSe services and, as a consequence, trigger the relevant handsetconfiguration.Thetriggeringprocessisnetworkspecificandoutsidethescopeof thisspecification. Analternativetothisautomatedmechanismcouldbeamanuallytriggeredconfiguration (e.g.requestedbyanoperatorinastore).
2.2.2.1.1 Additionalfirsttimeconfigurationscenarios
Inadditiontothescenariodescribedintheprevioussection(firsttimetheuserregisters withtheIMSnetwork),thereareseveraladditionalscenarioswheresamesequence applies: When the customer changes to another RCSe enabled device: In this case, the sequence is identical with the only difference that the IMS provisioning (i.e. provisionIMSandRCSASaccounts)isnotrequiredasitwasperformedbefore. WhenthecustomerchangestheSIMcard:Inthiscase,thesequenceisidenticalto theonedescribedintheprevioussection. A configuration update implying changes in the users IMS identity (i.e. TELURI and/orSIPURI). A configuration update implying changes in the capability discovery mechanism: Aspresentedlaterinthedocument,switchingthecapabilitydiscoverymechanism parameterautomaticallytriggersthesameprocessdescribedinAnnexA(section A.2)asacomplementtotheRCSRelease2managedobjects.
2.2.2.1.2 Autoconfigurationmechanisms
This specification contemplates three alternative mechanisms in other to perform the autoconfigurationoftheRCSefunctionalityinterminals: OMADM5: This is the same mechanism proposed for RCS and based on the managedobjectconfigurationproposedinAnnexA,sectionA.2. OMACP 6 : This is an alternative mechanism (considering OMADMas thepreferredstandard mechanism for RCSe) based on the OMACP specific configurationproposedinAnnexA,sectionsA.2andA.3
Although the previous mechanisms are preferred, the RCSe specification proposes an alternative optional mechanism which can be requested by a MNO (i.e. during customization)withthefollowingmaingoals: Reducingcomplexity(OMADMimplementationcanberelativelycomplex)
ConsistentlywithRCSRelease2specifications,theOMADMversionwhichshallbeimplementedforRCSe deviceconfigurationisOMADMversion1.2. 6 TheOMACPversionwhichshallbeimplementedforRCSedeviceconfigurationisOMACPversion1.1.
Page 26 of151
RCSeAdvancedComms: Servicesandclientspecification Enablingaconfigurationproceduretransparenttotheuser(OMACPdrawback) Reducingautodetectionmechanismcomplexity
The new mechanism is based on a HTTP (HTTPS) request made by the handset to a configurationservertogettheconfigurationdata: Every time the handset boots, there is an initial HTTPS request to the RCSe configurationservertogetthecurrentconfigurationsettingsversion Incasetheversionsdonotmatch,theserverwillincludeaconfigurationXMLwith allthesettings.ThisconfigurationXMLwillbeidenticaltotheoneusedinOMACP (contentsarecoveredindetailinAnnexA,sectionsA.2andA.3). Ifitisnecessarytoforceareconfiguration(e.g.SIMcardswap),thehandsetwill reset the version value to 0 (the server configuration shall always have a value biggerthan0). If the MNO has to disable the RCSe functionality from a handset/client, the responsewillbeanemptyXMLsettingtheversionto0. Thedetailedontheexchanges(e.g.formatemployedfortherequests)arecovered below:
Thisalternativeconfigurationmechanismworksonthefollowingpreassumptions: Asasecuritymeasureandtomakesurethenetworkcanimplementthenecessary procedurestoresolvetheusersMSISDN(i.e.RADIUSrequests,headerenrichment, etc.), the configuration can only take place if connected using an MNO PS data networkand,therefore,thehandsetshouldhavethenecessaryAPNconfiguration toperformtheconnection. FromtheUXpointofview,thecustomerisnotawareoftheconfigurationprocess (i.e.backgroundprocesswithnopopupsornotificationsshownonthescreen).
Itshouldalsobenotedthatthismechanismalsocontributestoreducethecomplexityof theautodetectionmechanismbecausethehandsetwillproactivelyrequestanupdateof theconfigurationsettingseverytimethehandsetisrebooted. request: Initial HTTPS UEUser/ClientA MNOCoreNW RCSe Phone Client configserver Logic Logic Bootupcompleted HTTPSREQUEST (https://config.<mcc><mmc>.rcse?vers=1)
Figure5.RCSealternativeconfiguration:Initialrequest
Page 27 of151
RCSeAdvancedComms: Servicesandclientspecification The version of the configuration currently available on the handset is passed as GETparameterintherequest(vers=<versionnumber>;pleasenotetheversionis either 0 or a positive integer). If the configuration is damaged, nonexistent or followsaSIMchangetheversionnumberissetto0. Thehandsetshalluseastandardqualifieddomaintomaketheresponse: o https://config.<mcc><mmc>.rcse(e.g.https://rcseconfig.24423.com). Consequently, the MNO DNS will resolve this private domain into the RCSe configurationserverIPaddress. RCSeconfigurationserverresponse:
Figure6.RCSe configuration:
UEUser/ClientA Phone Logic Client Logic
MNOCoreNW RCSe configserver
Currentversionis differentfromthe oneprovidedbythe client
HTTPS200OK (containsconfigXML)
ParseXML,apply configuration
alternative Server response
Theserverchecksiftheversionprovidedbytheclientmatchesthelatestversion oftheconfigurationavailableontheserver. Iftheversionmatches,theXMLwillbeempty:

<?xml version="1.0"?> <wap-provisioningdoc version="1.1"> </wap-provisioningdoc> Table6.RCSealternativeconfigurationemptyXML(noconfigurationchangesrequired)
IftheMNOwouldliketodisabletheRCSefunctionalityfromahandset/client,the responsewillbeaXMLcontainingonlytheversionsetto0:
Page 28 of151
<?xml version="1.0"?> <wap-provisioningdoc version="1.1"> <characteristic type="VERS"> <parm name=version value=X/> </characteristic> </wap-provisioningdoc> Table7.RCSealternativeconfigurationemptyXML(resetRCSeclient)
If not, the response will contain a configuration XML (i.e. contenttype text/xml) configurationthattheclientneedstoparseandapply: o TheXMLformatisidenticaltotheoneuseforOMACPconfiguration(see Annex A, sections A.2 and A.3) with a new parameter addition to include theversion:
<?xml version="1.0"?> <wap-provisioningdoc version="1.1"> <characteristic type="APPLICATION"> <parm name="APPID" value="RCS-e"/> </characteristic> <characteristic type="VERS"> <parm name=version value=X/> </characteristic> <characteristic type=IMS> </characteristic> <characteristic type=APPAUTH> <parm name=AuthType value=X/> <parm name=Realm value=X/> <parm name=UserName value=X/> <parm name=UserPwd value=X/> </characteristic> <characteristic type=PRESENCE> </characteristic> <characteristic type=XDMS> </characteristic> <characteristic type=CAPDISCOVERY> </characteristic> <characteristic type=APN> </characteristic> <characteristic type=OTHER> </characteristic> </wap-provisioningdoc> Table8.RCSealternativeconfigurationXMLstructurebasedonOMACP
Page 29 of151
RCSeAdvancedComms: Servicesandclientspecification 2.2.2.2 Registration UserAisprovisionedforserviceandthefirst/timeregistrationhasalreadytakenplace. TheuserwasnotregisteredisnowtryingtoperformaregistrationusingPS,andtherefore assumingthatSSO/GIBAauthenticationisavailable: UEUser/ClientA MNOIMSCore MNOCore RCSAS Phone Client NW PS XDMS Logic Logic Phoneconnectedto InternetviaPSanditis notRCSregistered SIPREGISTER SIP200OK(expiryvalue providedbytheIMSCore) Restartreregistrationtimer ONLYIFENABLEDVIA CONFIGURATION Thepublicationonlyhappensif theUSEPRESENCEparameteris set1(seeTable5) SIPPUBLISH(capabilities) SIP200OK Registrationcompleted
Figure7.RegistrationfromofflineoverPS(assumingSSO/GIBA)
Iftheinitialauthentication(SSO/GIBA)fails(i.e.theMNOequipmentdoesnotsupportit or the user is trying to register via WiFi), the client must then retry using digest authentication(USER+PASSWORD).
Page 30 of151
RCSeAdvancedComms: Servicesandclientspecification UEUser/ClientA Phone Logic Client Logic WiFiorPS NW MNOIMSCore RCSAS
PS XDMS
Phoneconnectedto InternetviaWiFi
SIPREGISTER SIP401UNAUTHORISED(challenge) SIPREGISTER(sec.header:USER andPASSWORD) SIP200OK(expiryvalue providedbytheIMSCore)
Restartreregistrationtimer ONLYIFENABLEDVIA CONFIGURATION Thepublicationonly happensiftheUSE PRESENCEparameteris set1(seeTable5)
SIPPUBLISH(capabilities) SIP401UNAUTHORISED
SIPPUBLISH(capabilities,sec. header) SIP200OK

Registrationcompleted
Figure8.RegistrationfromofflineoverWiFiorPSnetworkswithoutSSO/GIBAauthenticationsupport
Pleasenotethatinthesamescenariosandprovidedtheterminalisconfiguredtohandle presencerelatedfunctionality(USEPRESENCEset1aspresentedinTable5),itshouldbe notedthat: The publication shall follow the procedures defined in [RCS1TECREAL] 7 and [RCS2TECREAL] 8 (e.g. use of the defined Servicedescriptions and the PublishTimerexpirytimer). XCAPexchangesshallanywaysupportXCAPexchangesaccordingtotheprocedure defined in [RCS1TECREAL] and [RCS2TECREAL] and authentication parameters definedin[RCS2TECREAL]).Inadditiontothis,theXDMSexchangesmayalsouse the same security mechanism based on digest authentication using the same parametersasforSIPmessages:
7 8
RichCommunicationSuiteRelease1TechnicalRealization2.0,14February2011 RichCommunicationSuiteRelease2TechnicalRealization2.0,14February2011
Page 31 of151
RCSeAdvancedComms: Servicesandclientspecification UEUser/ClientA Phone Logic Client Logic WiFiorPS NW MNOIMSCore RCSAS
PS XDMS
XCAPcanbealso authenticated.The recommendationisto usethesame USER+PASSWORD usedforSIP
XCAPXXX XCAP401UNAUTHORISED (challenge) XCAPXXX(Authheaderuser+pwd) XCAP200OK
Figure9.XCAPexchangeswhenusingdigestauthentication
2.2.2.3 Reregistration User A is already registered, however registration expires (timer since last registration reaches the expiry value provided by the network). In this case, the client needs to re register following the flow presented below. Please note for simplicity, in the following diagramwehaveassumedthatSSO/GIBAauthenticationisavailable. UEUser/ClientA MNOIMSCore MNOCore RCSAS Phone Client NW PS XDMS Logic Logic Registrationtime expires SIPREGISTER SIP200OK(expiryvalue providedbytheIMSCore) Registrationcompleted,restart reregistrationtimer
Figure10.Reregistration
Page 32 of151
RCSeAdvancedComms: Servicesandclientspecification 2.2.2.4 Deregistration UserAisregisteredhoweverbasedonthephonelogic,theconnexiontotheserviceisno longerpossible.Amongthepossiblereasons,wehavelistedthemostrelevant: poweringdown,batterylow, UEUser/ClientA MNOIMSCore MNOCore RCSAS Phone Client NW PS XDMS Logic Logic OSdetectsrelevant condition Clientisnotified (event)detects relevantcondition SIPREGISTER(exp=0) SIP200OK Clientsend terminationsignal toOS
Figure11.Deregistration
2.2.2.5 Registrationstatusandavailablecapabilities In case the registration process is not successful or following a deregistration, the user shouldnotbeabletoaccessanyRCSeserviceandallRCSecontactsservices/capabilities shallbereportedtotheuserasnotavailableindependentlyofanysetting(e.g.theIMCAP ALWAYSONsettingpresentedinTable5 isignored). 2.2.2.6 Registrationfrequencyoptimization RCSe client shall not send more register request than what is needed to maintain the registrationstateinthenetwork.WhentheIPconnectivityislostandrestoredwiththe sameIPaddress,theRCSeclientshall: only send a register refresh upon retrieval of IP connectivity if the duration for sendingaregisterrefreshsincethelastregisterhasbeenexceeded, onlysendaninitialregisteruponretrievalofIPconnectivityiftheregistrationhas expired,and, notsendderegisterrequestuponimminentlossofIPconnectivity.
2.3 Capability discovery

ThecapabilityorservicediscoverymechanismiskeytoRCSe.Thecapabilitydiscoveryisa processwhichenablesausertounderstandthesubsetRCSeserviceswhichareavailable toaccessand/orcommunicatewithothercontactsatcertainpointoftime.
Page 33 of151
2.3.1 CapabilitydiscoveryprocessthroughOPTIONSmessage
TheprimaryandmandatorymethodforcapabilitydiscoveryisbasedontheSIPOPTIONS message,apeertopeermessageexchangedbetweenclients. WhenaSIPOPTIONSmessageissentfromUserAtoUserB,UserAwillreceiveoneof3 typesofresponse: 1) User B is Registered and the response from User Bs client will comprise CAPABILITY STATUS the set of services currently available (using tags as describedinsection2.3.1.1). Note the response must contain, at least, the RCSe IM tag (+g.3gpp.iari ref="urn%3Aurn7%3A3gppapplication.ims.iari.rcse.im"). If it is contained there,theresponsewillbeequivalenttothecasepresentedbelowinbullet 3.
2) If User B is currently not registered (e.g. phone is off), then the network will respondwithoneofthefollowingmessageerror:480TEMPORARILYUNAVAILABLE (gracefulderegistrationtookplace)or408REQUESTTIMEOUT. 3) If User B is not provisioned for RCSe the network will respond with a message error:404NOTFOUND9. Notethatfromauserexperienceperspectiveresponse2)10and3)arethesameandno RCSeserviceswillbeshowntoUserAasavailabletocommunicatewithUserB. TheSIPOPTIONSmessageshallbesentinthefollowingscenarios: post first time registration to obtain the registration state and default set of capabilitiesforeachcontactinthephoneaddressbook(noteoneSIPOPTIONSis sent per IMS identity [i.e. TELURI/MSISDN or SIPURI] stored in the address book)11, whenanewcontactisaddedtothephoneaddressbook, periodically (frequency determined by the POLLING PERIOD parameter as presented in section 2.1 Table 5) to all the contacts in the phone address book whose capabilities are not available (e.g. nonRCSe users) or are expired (see CAPABILITYINFOEXPIRYparameterinsection2.1Table5forreference),
Pleasenotethattheresponseprovidedmaydependonthenetworkconfiguration.Abetterapproachfor theterminalistoparsetheresponseandifitisnoteithera200OKcontainingthecapabilitiesasfeature tags,a480TEMPORARILYUNAVAILABLEora408REQUESTTIMEOUT,thetargetusershouldbeconsidered as nonRCS. For simplicity, the present document assumes in the following sections that the response providedbytheMNOcorenetworkisalways404NOTFOUND,however,thepreviousstatementshouldbe takenintoaccount. 10 Please notethat inthiscase if IM CAPALWAYSON(see Table 5) is enabled, the IM/chat should still be reportedtotheuserasavailableeventheotherendisnotregistered. 11 PleasenoteacontactmayhaveseveralMSISDNsorassociatedSIPURIs.TheclientwilluseALLtheusers MSISDNs/SIPURIstosendSIPOPTIONSmessages.Ifitisdiscoveredthatmorethanoneoftheassociated TELURIs/SIPURIs are IMS provisioned, each will be treated as a separate RCSe user. For example, if displayingthelistofRCSecontacts,twoormoreentriesforauserwillbeshown(JohnSmithmobileand JohnSmithhome),sotheusercanchoose.
Page 34 of151
RCSeAdvancedComms: Servicesandclientspecification whenacontactsprimaryMSISDNismodified oranewMSISDNisadded(where users have several subscriptions and each subscription is potentially associated withaRCSeaccount), when checking the available RCSe services/capabilities to communicate with anotheruser(e.g.fromtheaddressbookandcalllog), attheestablishmentvoicecalltoobtaintherealtimecapabilitiesforthecallorIM sessionprovidedthishasnotbeenperformedbefore(seepreviousbullet), during a voice call, file transfer or IM session when the relevant available capabilitieschange,and, whenthereisacommunicationsevent(text,email,callorIM)withanotheruserin theaddressbook.
Please note that in some cases it is not required because the options exchange just happened shortly before the communication takes place (e.g. to send the SMS, the user went to the addressbook, selected a user [options exchange takes place] and choosestosendaSMS). UEUser/ClientA Phone Logic Client Logic MNOCore NW MNOIMSCore RCSAS
PS XDMS
OPTIONSmessage mechanism.We areassumingUser BisREGISTERED, UserCisNOT REGISTEREDand UserDisNOTan RCSeuser
SIPOPTIONS(userB) SIP200OK(capabilitiesuserB) SIPOPTIONS(userC) ERROR480TEMPORARILYUNAVAILABLE/408REQUESTTIMEOUT Routed to/from SIPOPTIONS(userD) userB ERROR404NOTFOUND
Figure12.CapabilitiesdiscoveryviaSIPOPTIONSmessage
2.3.1.1 SIPOPTIONSmessageextensiontosupportcapabilitydiscovery The RCS (Release 1 and 2) specifications only provide a mechanism to exchange the capability status (based in SIP OPTIONS exchange) regarding to image and video share servicesduringacall.Thismechanismisbasedintheuseoftagscontainedtransportedin theAcceptcontactandContactheadersfortheSIPOPTIONSanditsresponses:
Page 35 of151
RCSeAdvancedComms: Servicesandclientspecification The tags corresponding to the set of functionalities supported by the requesting terminal at the time this request is made are carried in both the Contact and AcceptcontactheadersoftheSIPOPTIONSmessage. Thetagscorrespondingtothesubsetofthefunctionalitiesthataresupportedby thereceiverareincludedintheContactheaderofthe200OKresponse.
ConsequentlywiththeRCSRelease2specification,thefollowingtagscanbeemployedto identifyimageandvideoshareservicecapabilities: RCSeservice Imageshare Videoshare Tag +g.3gpp.iariref="urn%3Aurn7%3A3gppapplication.ims.iari.gsmais" +g.3gpp.csvoice

Table9.StandardRCSRelease2SIPOPTIONStags
In order to support the full service discovery functionality consistently presented in this document, it is necessary to extend the tag mechanism by performing the following changes: Thereisoneuniquetag(+g.oma.sipim)traditionallyassignedtotwoservices(IM andfiletransfer).NeverthelessandinordertobothuniquelyidentifyRCSeclients and provide per service capability granularity the following changes are introduced: o +g.3gpp.iariref="urn%3Aurn7%3A3gppapplication.ims.iari.rcse.im" tag is usedONLYtoidentifytheRCSeIMservice12,and, o +g.3gpp.iariref="urn%3Aurn7%3A3gppapplication.ims.iari.rcse.ft" tag is definedtouniquelyidentifyfiletransferservice RCSe service IM/Chat Filetransfer For those clients supplementing the RCSe functionality with the social informationviapresence 13 functionality(i.e.thePRESENCEPROFILEparameteris setto1;seeTable5),anewtagisdefinedtorepresentsuchfeatures: Tag +g.3gpp.iariref="urn%3Aurn7%3A3gppapplication.ims.iari.rcse.im" +g.3gpp.iariref="urn%3Aurn7%3A3gppapplication.ims.iari.rcse.ft"
Table10.AdditionaltagstocovertheremainingRCSeservices
Although the RCSe IM service is based and endorses the OMAIM definition, it comes with some customizations and additional functionalities which makethe potential interaction with standard OMAIM clients nonideal from the UX point of view. Consequently, a new tag has been defined to signal that differences and distinguish the RCSe IM service for nonRCSe clients supporting the standard OMAIM functionality. 13 By this term we are referring to the set of functionalities defined in the RCS Release 1 and Release 2 standardsandpresentedin[RCS1TECREAL]insectionsfrom2.1.2to2.1.6.
12
Page 36 of151
RCSeAdvancedComms: Servicesandclientspecification o The +g.3gpp.iariref="urn%3Aurn7%3A3gppapplication.ims.iari.rcse.sp" tagidentifiesthecontactssupportingthesocialinformationviapresence features. Forthoseclientswillingtoimplementadiscoverymechanismbasedonpresence (i.e.thePRESENCEDISCOVERYparameterissetto1;seeTable5),independently onwhetherthesocialinformationviapresencefunctionalityissupportedornot, anewtagisdefined: o The +g.3gpp.iariref="urn%3Aurn7%3A3gppapplication.ims.iari.rcse.dp" tagidentifiesthecontactssupportingcapabilitydiscoveryviapresence. RCSeservice IM/Chat Filetransfer Imageshare Videoshare Socialpresence information Capability discoveryvia presence Tag +g.3gpp.iariref="urn%3Aurn7%3A3gppapplication.ims.iari.rcse.im" +g.3gpp.iariref="urn%3Aurn7%3A3gppapplication.ims.iari.rcse.ft" +g.3gpp.iariref="urn%3Aurn7%3A3gppapplication.ims.iari.gsmais" +g.3gpp.csvoice +g.3gpp.iariref="urn%3Aurn7%3A3gppapplication.ims.iari.rcse.sp"
+g.3gpp.iariref="urn%3Aurn7%3A3gppapplication.ims.iari.rcse.dp"
Table11.CompleteSIPOPTIONStagproposalforRCSe
Please note that the new tags defined in this section should be ONLY employed for SIP OPTIONSexchangesandthatthestandardtagsshouldbeusedtoidentifytheservicesin the rest of relevant SIP transactions (i.e. +g.oma.sipim for chat/IM). Note also that the +g.oma.sipimfeaturetagmayalsobelistedduringthisOPTIONSexchange. 2.3.1.2 Futureextensionstothemechanism InadditiontothementionedadditionsandtoallowaMNO(orgroupofMNOs)todeploy additional services which can also benefit from the RCSe discovery mechanism, an additionaltagformatisdefined: +g.3gpp.iariref="urn%3Aurn7%3A3gpp application.ims.iari.rcse.<operatorID>.<servicename>"14 Validexamplesare: o +g.3gpp.iariref="urn%3Aurn7%3A3gppapplication.ims.iari. rcse.OR.serviceA" o +g.3gpp.iariref="urn%3Aurn7%3A3gppapplication.ims.iari. rcse.TEL.serviceB"
14
Page 37 of151
RCSeAdvancedComms: Servicesandclientspecification o +g.3gpp.iariref="urn%3Aurn7%3A3gppapplication.ims.iari. rcse.TI.serviceC" o +g.3gpp.iariref="urn%3Aurn7%3A3gppapplication.ims.iari. rcse.DT.serviceD" o +g.3gpp.iariref="urn%3Aurn7%3A3gppapplication.ims.iari. rcse.VF.serviceE" Please note the operatorID and the serviceName are up to each MNO choice. The only requirement for a MNO following this approach is to include these tags in the relevant interoperabilityagreementswithotherMNOstoavoidanyinteroperabilityissues. RCSeservice Operator specificservice Tag +g.3gpp.iariref="urn%3Aurn7%3A3gppapplication.ims.iari. rcse.<operatorID>.<servicename>"
Table12.SIPOPTIONStagproposalforfuturelinesofwork
Please also note a set of LTE specific tags have been defined as part of the RCSe specificationandarecoveredindetailinsection2.12.2. 2.3.1.3 SIPOPTIONSexchangeoptimisations Aspresentedinsection2.3.1,thereareseveralscenarioswheretheSIPOPTIONSmessage hastobeusedtoupdatethecapabilities.Dependingonthecircumstancesandusecases, there could be occasions where the OPTIONS message exchange may happen relatively often(i.e.veryfrequentGPRSbearerchanges). Toavoidtheoverheadandincreasetheefficiency,theclientmayimplementamechanism tothosesituationswheretheOPTIONSmessageexchangehappenstoooften.Examplesof howthismechanismcanbeachievedarelistedbelow: Introduceadegreeofhysteresis(i.e.acapabilitiesupdateissent/requestedonly whenthecircumstanceswhichledtothechangeremainstableforacertainperiod oftime). Implementavaliditytimer(i.e.ifthelatestcapabilitieswehavewerefetchedless thanXsecondsago,theyarestillconsideredasvalid).
Please note this spec does not specify the specific mechanisms which should be implemented leaving space to OEMs and third parties to drive innovative and differentiatedsolutions,whichdifferentiatestheirproductsfromcompetitors. 2.3.1.4 UIintegrationoptimisations In addition to the optimizations to minimize the traffic generated by the SIP OPTIONS exchanges when possible, there are two additional optimizations related with the discoverymechanismintegrationontheUIthatshouldbetakenintoaccount: The round trip time for a SIP OPTIONS exchange (send and receive response) is expectedtorangevaluesunder1second.Takingthisintoaccount,theUIhastobe optimizedtominimizetheimpactofthisexchangedelay.
Page 38 of151
RCSeAdvancedComms: Servicesandclientspecification When sending the SIP OPTIONS messages to several users (e.g. first time registration or when polling), it is recommended to employ a nonaggressive strategyandallowingtimebetweeneachexchangeto: o Minimizepotentialnetworkimpact o Avoidanyimpactontheuserexperience(e.g.slowerUI,blockings,etc.)
Please note that again in this case this spec does not specify the specific mechanisms whichshouldbeimplementedleavingspacetoOEMsandthirdpartiestodriveinnovative anddifferentiatedsolutions,whichdifferentiatestheirproductsfromcompetitors. 2.3.1.5 SIPOPTIONSandmultidevicesupport Ultimately, the choice of supporting multidevice is up to each individual MNO. The considerations contained in this section will only apply to those operators willing to includeRCSemultidevicesupportintheirnetworks. In a multidevice scenario, when the user is registered on the IMS CORE with different devicesusingthesameIMSidentity(i.e.TELURIorSIPURI),theOPTIONSexchangewill returnincompleteinformation: The capabilities contained in the OPTIONS message refer only to the originating device(i.e.theoriginatingusermaybeloggedinwiththesameTELURIinseveral devices). TheIMSCore,dependingontheconfiguration,eithersendstheOPTIONSmessage to the first registry in the IMS CORE or forks the OPTIONS to all the registered devices. In any case, only the first response is passed back to the requester, discarding the others. In other words, the capabilities returned in the OPTIONS responsewillbetheonesfromonlyoneofthedevicesoftheuser.
ThepreferredimplementationforhandlingtheOPTIONSinamultideviceenvironmentis leftupMNOdiscretionwiththeonlyrequirementthatitshouldnothaveimpactonthe terminal side (i.e. no changes on the client side). A possible solution for extending the OPTIONSmechanismtoamultidevicescenarioistoincludeacustomApplicationServer implementingthefollowinglogic: AtriggerwillbesetupintheIMSCOREtosendalltheOPTIONSfromanRCSeuser totheAS. The AS will fork the OPTIONS request to all the user registered devices and will aggregateallthecapabilitiesreturnedintooneOPTIONSresponsemessageincase theforkingisnotalreadyimplementedbytheIMScorenetwork. Once the responses from the different multidevices are received, the AS will aggregateallthecapabilitiesfromtherepliesandsentthembacktothecaller. Evennotallthereplieshavebeenreceivedinlessthanaconfigurableamountof time (note the recommendation is to set the value to optimise the UX on the terminal)theASwillreturntheaggregatedinformationreceivedsofar.
In order to implement this feature, an application server should be able to uniquely identifyeachuserdevicetoperformtheforkingoftheOPTIONSmessageandtointercept
Page 39 of151
RCSeAdvancedComms: Servicesandclientspecification andprocesstheresponses.Themechanismtohavetheseindividualidentities(GRUU)is coveredinsection2.14. WhilemultidevicesupportisanitemlefttoeachMNOtodecidewhetheritissupported ornot,theRCSecapabilitydiscoverymechanismbasedontheSIPOPTIONSmessageisa mandatory requirement and the behaviour will be the one specified before to ensure seamlessinterworkingbetweenMNOs.
2.3.2 Capabilitydiscoveryviapresence15
InadditiontotheSIPOPTIONSmechanismdefinedinsection2.3.1,theMNOdeployinga presenceservermayprovidethecapabilitydiscoverymechanismviapresenceasdefined insection4of[RCS1TECREAL]andsection6of[RCS2TECREAL]. ThismechanismcanbeusedbyaclientwhosePRESENCEDISCOVERYparameterhasbeen set to 1, and only with contacts who have been identified as RCSe capable as per the proceduredefinedinsection2.4.1,andwhohaveindicatedthesupportofdiscoveryvia presence(i.e.the+g.3gpp.iariref="urn%3Aurn7%3A3gppapplication.ims.iari.rcse.dp"tag wasincludedeitherintheOPTIONSmessageorresponse). Please note the contact will be also added to an XDM list of contacts supporting this feature so it is possible to optimize future capability polling as described in section2.3.2.1.
Effectively, the RCSe client needs to have the necessary functionality to distinguish between contacts who support the presence capability discovery and those who do not (e.g.storingitasapropertyintheaddressbook). As a reference, the capability discovery mechanism via presence (based on capabilities publicationandanonymousfetch)ispresentedbelow: Each client supporting the capability discovery via presence will publish its capabilitiesonthepresenceserver(SIPPUBLISH)whenregistering When querying, the client polls each one or more contacts (list) capability status using the SIP ANONYMOUS SUBSCRIBE requests with an expiry time of 0 and processingtheNOTIFYresponses. The NOTIFY response contains the capabilities as described in the RCS Release 2 datamodel16.
15
It is assumed that the operator implementing this mechanism has a policy where the RCS service capabilitiescanbefetchedviaanonymoussubscribe.Otherwise,thismechanismcannotbeimplemented. 16 [RCS2TECREAL],Section4.2
Page 40 of151
UEUser/ClientA Phone Logic Client Logic MNOCore NW MNOIMSCore RCSAS
PS XDMS
SIPOPTIONS(userB)
SIP200OK(capabilitiesuserB, Includes+g.3gpp.app_ref="urn%3Aurn7%3A3gpp application.ims.iari.rcse.im"tag)
NexttimeUserB capabilitiesare checked
SIPANONYMOUSSUBSCRIBE (userB,exp=0) SIP200OK SIPNOTIFY(UserBcapabilities)
Figure13.CapabilitiesdiscoveryviaPRESENCE
2.3.2.1 EnhancingANONYMOUSSUBSCRIBEmechanismwithXDMSlists The standard mechanism can be enhanced by using a XDMS list of all the contacts supportingthepresencebasedcapabilitydiscoverymechanismintheAddressBookand subscribing once to the list instead of one SUBSCRIBE per contact. This will return an aggregated NOTIFY message instead of several message making the mechanism more efficient, particularly in those scenarios where the whole contact list status/capabilities mustbequeried. Inthisparticularscenario,itisrelativelylikelythattheterminaladdressbookmayalready containseveralcontacts,therefore,generatingaXDMSlistatthistimeanduseittoquery, reducestheamountofmessagesexchangedwiththepresenceserver. For the scope of this document it is considered that the XDMS list mechanism enhancementisimplementedandused.
2.4 New user discovery mechanism

WiththemainaimofoptimisingtheUXandminimisingtheunnecessarytrafficgenerated byanRCSeclient,alistcontainingthesubsetofRCSecontactsshouldbegeneratedand maintained by the client. This list should include both registered and not registered contacts;incontrast,itdoesnotincludenotprovisionedcontacts. Inadditiontothis,thefirstviewoftheaddressbookshallclearlyidentifytheRCSe capablecontactsthankstothelist,withavisualRCSeflag.
Page 41 of151
RCSeAdvancedComms: Servicesandclientspecification In order to keep this list updated, when a new contact is added to the phonebook it is necessarytoevaluatewhetherisanRCSecontactusingthestandardcapabilitydiscovery basedonSIPOPTIONS. Finally note that a new contact may come from different sources and, therefore, the mechanism described in the following sections applies to all the scenarios presented below: Addedmanuallybytheuser Synchronizedvia3rdpartyserversorPC ReceivedviaBluetoothorhandlingaVCARDfilereceived,forexampleviaemail
2.4.1 DiscoveryviaOPTIONSmessage
TheSIPOPTIONSmessagecanbeemployednotonlytodeterminethecapabilitiesbutalso to identify whether a contact is or not an RCSe user, independently whether he/she is registeredatthetimethequeryisperformed. WhenaSIPOPTIONSmessageissentfromUserAtoUserB,UserAwillreceiveoneof6 typesofresponse: 1) User B is Registered and the response from User Bs client will comprise CAPABILITY STATUS the set of services currently available (based on tags as describedinsection2.3.1.1).Therefore,ifthisresponseisreceivedandatleastthe RCSe IM service tag (+g.3gpp.iariref="urn%3Aurn7%3A3gpp application.ims.iari.rcse.im")isincluded,theuserisidentifiedasaRCSeuser. 2) IfUserBiscurrentlynotregistered(e.g.phoneisoff,outofcoverageorroaming with data services disabled), then the network will respond with one of the following error messages: 480 TEMPORARILY UNAVAILABLE (graceful deregistration took place) or 408 REQUEST TIMEOUT. From the user discovery pointofview,thisresponseisignored: IfuserBwaspreviouslyidentifiedasanRCSeuser(i.e.optionsmessageor a complete 200 OK response with the capabilities was received from him/herbefore),itwillremainlikethat. Otherwise,theuserwillremainasanonRCSeuser
3) If User B is not provisioned for RCSe the network will respond with a message error: 404 NOT FOUND17. Therefore, if this message is received, the user is identifiedasanonRCSeuser.
Pleasenotethattheresponseprovidedmaydependonthenetworkconfiguration.Abetterapproachfor theterminalistoparsetheresponseandifitisnoteithera200OKcontainingthecapabilitiesasfeature tags,a480TEMPORARILYUNAVAILABLEora408REQUESTTIMEOUT,thetargetusershouldbeconsidered as nonRCS. For simplicity, the present document assumes in the following sections that the response providedbytheMNOcorenetworkisalways404NOTFOUND,however,thepreviousstatementshouldbe takenintoaccount.
17
Page 42 of151
RCSeAdvancedComms: Servicesandclientspecification 4) Inadditiontothis,ifaSIPOPTIONSisreceivedandatleasttheRCSeIMservicetag (+g.3gpp.iariref="urn%3Aurn7%3A3gppapplication.ims.iari.rcse.im") is included, the sender is identified as an RCSe user. In this particular case, when user B receivestheOPTIONSmessagewithcapabilitiesfromuserA,userBidentifiesuser AasanRCSeuser. 5) IfUserBwasidentifiedasaRCSeuserandtheresponsetotheOPTIONSmessage indicatesthatUserBisnolongeraRCSeuser(nolongerprovisionedasdescribed in the previous bullet point 3 or the RCSe IM tag [+g.3gpp.iariref="urn%3Aurn 7%3A3gppapplication.ims.iari.rcse.im"] is no longer included), user B should be identifiedasanonRCSeuserand,consequently,removedfromthelistofRCSe whichismaintainedinthehandsetordevice. 6) PleasenotethereisapossibilityaRCSeuserwhoisnotwithintheaddressbook contactsmaysendOPTIONSmessagesorresponses(e.g.whenreceivingacallor making a call using a MSISDN not included in the contacts). In this case the capabilities shall be stored temporarily in the terminal for one of the following purposes: Use the value during a subsequent IM/chat, file transfer or call (image/videoshare),and, To add the information to the new contact (both the fact that it is a RCSeuserandthecachedcapabilities)incasetheuserdecidestoadda newaddressbookentryfollowingacommunication.
To illustrate the behaviour, the following example is provided. User A is registered and decidestoaddormodifyanewcontactwhichresultsinanewIMSidentityforthecontact (e.g. new MSISDN which implies a new TELURI). As a consequence, the client needs to verifywhetherthecontactisanRCSeuserand,therefore,addittothelisttheterminal maintains.
Page 43 of151
RCSeAdvancedComms: Servicesandclientspecification UEUser/ClientA Phone Logic Client Logic MNO Core NW MNOIMSCore RCSAS
PS XDMS
UEUser/ClientB Client Logic
Neworupdatedcontact Checkcapabilities/status
SIPOPTIONS (userAcapabilities)
IfthenewcontactisanRCS/IMS provisionedandhe/sheisregistered, wereceivethecapabilities
SIP200OK (capabilitiesnewcontact)
Otherwisewereceiveanerror.In thiscasetheuserisinitiallynot identifiedasaRCSuser
SIP480TEMPORARILYUNAVAILABLE/SIP408REQUEST TIMEOUT
Figure14.Adding/Editingacontact
Aspartofthecapabilities,thisprocesswillidentifythosecontactssupportingthesocial information via presence and the "capability discovery via presence" functionalities. Pleasenotethat: ifthePRESENCEDISCOVERYissetto1(seeTable5),theclientshouldalsoupdate theXDMlistofRCScontactssupportingthisfunctionalitywiththenewlyidentified contactssupportingthecapabilitydiscoveryviapresencefunctionality. if the PRESENCE PROFILE is set to 1 (see Table 5), the client may use the proceduresrelatedtotheexchangeof"socialinformationviapresence"definedin [RCS1TECREAL] with the newly identified contacts supporting the "social informationviapresence"functionality.
Page 44 of151
RCSeAdvancedComms: Servicesandclientspecification UEUser/ClientA Phone Logic Client Logic MNO CoreNW MNOIMSCore RCSAS
PS XDMS
XCAPGET(userA_contact_list) XCAP 200OK(contact_list) or404NOTFOUND XCAPPUT(userA_contact_list) XCAP200OK or 404NOTFOUND Figure15.UpdatingtheXDMSlistofcontactssupportingsocialinformationviapresencefunctionality
Additionally, it should be noted that if User A is NOT registered at the time the new contact(s)areadded,theterminalshouldkeepthenecessaryinformationinthephoneso thenexttimetheRCSeclientcompletestheregistrationprocessdescribedinFigure14 and,ifapplicable,Figure15.
2.5 Capability polling mechanism

In order to enhance the discovery of new users and, ultimately, keep the list of RCSe contacts up to date, the present specification proposes a mechanism, capability polling, consisting in polling the status/capabilities of all the contacts contained in the addressbook whose capabilities are not available (e.g. nonRCSe users) or are expired (seeCAPABILITYINFOEXPIRYparameterinsection2.1Table5 forreference), It should be noted that the capability polling mechanism is optional and will be only performed if the right configuration is in place (i.e. if the POLLING_PERIOD parameter presentedin Table5issetto0,thispollingmechanismwillnottakeplace). Assuming the POLLING_PERIOD is configured to be greater than 0 and after the polling timerexpires,theclientwillperformthefollowingmechanismtoupdatethelistofRCSe contactsandupdatetheircapabilities. Please note it should be taken into account that when using OPTIONS, the capability pollingisonlyperformedon: those contacts without capability information (nonRCSe users and RCSe users withunknowncapabilities),and, therestofRCSecontacts,providedtheassociatedcapabilityinformationisolder thattheCAPABILITY_INFO_EXPIRYparameter(see Table5 forfurtherreference)18.
18
Please note this is a traffic optimization to reduce the amount of SIP OPTIONS messages generated by capabilitypolling
Page 45 of151
RCSeAdvancedComms: Servicesandclientspecification UEUser/ClientA Phone Logic Client Logic MNOCore NW MNOIMSCore RCSAS
PS XDMS
Pollingtimerexpires
OPTIONSmessage mechanism.We areassumingUser BisREGISTERED, UserCisNOT REGISTEREDand UserDisNOTan RCSeuser
SIPOPTIONS(userB) SIP200OK(capabilitiesuserB) SIPOPTIONS(userC) ERROR480TEMPORARILYUNAVAILABLE/408REQUESTTIMEOUT SIPOPTIONS(userD) ERROR404NOTFOUND
Routed to/from userB
Restartpollingtimer (OnlyifPOLLINGTIMER>0)
Figure16.CapabilitiespollingviaOPTIONSmessage
Wepreviouslymentionedthatforclients/terminalsconfiguredwithPRESENCEDISCOVERY set to 1 (see Table 5) , an XDM list may be maintained containing those contacts supporting the capability discovery via presence. This list can be used to employ the anonymousfetch(ANONYMOUSSUBSCRIBE)mechanisminsteadofOPTIONS. Page 46 of151
UEUser/ClientA Phone Logic Client Logic MNOCore NW MNOIMSCore RCSAS
PS XDMS
Pollingtimerexpires
Notethelistpreviously storedintheXDMSis usedforthisquery (userA_contact_list)
SIPANONYMOUSSUBSCRIBE (userA_contact_list,exp=0) SIP200OK SIPNOTIFYs(RLSresponse)
RLSresponse(cached)
SIP200OK SIPNOTIFYs(capabilitiesper RCSregistereduser;aggregated response)
BoththeRLSresponse andsubsequent response(s)shouldbe combinedtogetthe completeresponse
SIP200OK
Restartpollingtimer (OnlyifPOLLINGTIMER>0)
Figure17.Capabilitiespollingviaanonymousfetch
Please note that an RCSe client should support both individual and aggregated NOTIFY responses19.
Depending on the networkconfiguration,only the firstnotification (RLS) may be the only one received willbereceivedbytheRCSeclientwithasubscriptionwithExpiryHeadervaluesetto0.Thedialoginthis IMS core is suppressed so the second notification will not be received by the RCSe client. So if the first notificationispartialandifwedon'treceivethesecondnotification,wepotentiallylostcapabilitiescontacts information. Thisproblematicrequiresfurtherstudyandwillbeaddressedinfutureversionsofthespecification. Page 47 of151
19
RCSeAdvancedComms: Servicesandclientspecification Finally, and as a summary of the capability and new user discovery mechanism compositionthefollowingdiagramisprovided.
FIRSTTIMEREGISTRATION (performedonly followinganOMADM/OMACPreconfiguration)
USEPRESENCE=0 USEPRESENCE=1
REGISTER
REGISTER PUBLISH<CAPABILITIES> SendOPTIONStoallcontacts
SendOPTIONStoall contacts
CREATEXDMSLIST<list>
USEPRESENCE=0
STANDARDREGISTRATION (restofregistrationscenarios)
USEPRESENCE=1
REGISTER
REGISTER
PUBLISH<CAPABILITIES> ADDING/MODIFIYNGACONTACT
USEPRESENCE=0 USEPRESENCE=1
SendOPTIONSto new/modifiedcontacts
SendOPTIONSto new/modified contacts UPDATEXDMS<list> (PRESENCEDISCOVERY=1and forcontactswithdiscovery presencetaginOPTIONS)
USEPRESENCE=0
PERIODICCAPABILITYPOLLING(POLLINGPERIOD>0)
USEPRESENCE=1
OPTIONStoallcontacts whosecapabilitieshave notbeenrecentlyupdated
OPTIONS(forcontactsnotsupporting
capabilitydiscoveryviapresenceand notinasocialpresencerelationship, andprovidecapabilitieshavenotbeen recently)
ANON.SUBSCRIBE<list>
(PRESENCEDISCOVERY =1)
LIVECAPABILITY/SERVICEDISCOVERY(Performedwhenacommunicationis likelytohappenortoupdatestatuswithinanexistingcommunication)) OPTIONS<contact> Figure18.RCSecapabilityandnewuserdiscoverymechanisms20
Thegreenboxesrepresentmandatoryprocedures,meanwhiletheclearboxesrepresentoptional procedures.
20
Page 48 of151
2.6 Management of supplementary RCS functionality

As presented in the introduction, a RCSe deployment (terminal and network) can be supplemented with the social information via presence21functionality (i.e. presence invitationandsocialinformationsharingfeatures)includedinRCSRelease2specifications, however,thisdoesnotformpartoftheRCSecompliance.Forthoseclientsimplementing thissetoffunctionalities,thefollowingprocedureisproposedtoensureinteroperability22: Priortobeabletosendaninvitationtoacontact(e.g.fromtheaddressbook),the terminal will use the OPTIONS mechanism to determine if the other end also supports this set of features (i.e. both ends include the +g.3gpp.iari ref="urn%3Aurn7%3A3gppapplication.ims.iari.rcse.sp" tag in the relevant headers). Ifbothclientssupportthesocialinformationviapresencefunctionality,thenthe user is presented with the possibility of inviting the contact to share the social presenceinformation.Ifnot,theterminalshouldnotpresentthispossibilitytothe userforthatcontact.
Themanagementofcontactssupportingthe"socialinformationviapresence"shallfollow the procedures defined in [RCS2TECREAL] and [RCS1TECREAL]. As such, the contacts withwhomtheuserhasestablishedasocialpresencerelationshipshallbeaddedtothe "rcs"listdefinedinsection4.4.2of[RCS1TECREAL].Ascapabilitiesarealreadyprovided viapresenceforthemembersofthe"rcs"list,theyshouldbeexcludedfromtheXDMlist definedinsection2.4.1
2.7 RCS-e and capabilities

TheRCSecapabilitiesrepresentthelistofservicesthataRCSeuser/clientcanaccessat certainpointoftime.Thecapabilitiesdependonfourfactors: User MNO provisioning status: An operator may choose to limit service to customersdependingonpaymentstatus(i.e.chatandfileshare,butnotvideo) TheterminalHW:AterminalwithlimitedHW(i.e.nocapabilitytoprocessvideo) maynotbeabletoaccessalltheRCSe Theterminalstatus:EvenifaterminalHWsupportsalltheservices,itcouldbethat the device status introduces a limitation (e.g. receiving files is not possible when thefilestorageisfull)
Please note that by the term social profile information, we are referring to all the related features present in RCS Release 2 which allow a user to create a social profile information, invite users to share, declare hyperability state and receive updates based on RCS presence functionality. Please note this functionalityiscoveredintheRCSRelease1specs,FunctionalDescriptionv2.0([RCS1FUNDESC]),sections 2.1.2,2.1.3and2.14. 22 PleasenotethatthepresentspecificationallowsthedeploymentofRCScommunicationserviceswithout theneedforapresenceserverandtheassociatedXDMservers,therefore,thepresentspecificationprovide thenecessaryguidancetosecureinteroperability.
21
Page 49 of151
RCSeAdvancedComms: Servicesandclientspecification Connectivitystatus:CertainservicesmayrequirecertainlevelofnetworkQoS.For example, streaming video over a 2G GPRS does not provide the adequate user experience.
Asasummary,pleasefindthetablebelow: SERVICE chat filetransfer (FT) TERMINALandSTATUS REQUIREMENTS None Minimumthresholdof freespacetostorefiles DATABEARER 2G Y EDGE Y 3G Y Y HSPA Y Y WiFi Y Y
MNO MNO choice choice MNO MNO choice choice
Minimumthresholdof freespacetostorefiles. Theterminalshouldbe onanactivecall23with Imageshare theusertheimageis willingtobesharedwith. Notavailablein multipartycalls. Supportvideoprofile (encoding/decoding). Videoshare Theterminalshouldbe (separate onanactivecall24with en/decoding) theusertheimageis willingtobesharedwith. Itisnotavailablein multipartycalls.
One way only
Y25
Y26
Table13.RCSeservicesHWanddatabearerrequirements
Inthiscontext,thetermactivecallisusedtoindicatethatavoicecallistakingplacewiththeuserthe imageissharedwithandthatthiscallisnotonhold,waitingorforwarded/diverted. 24 Inthiscontext,thetermactivecallisusedtoindicatethatavoicecallistakingplacewiththeuserthe videoissharedwithandthatthiscallisnotonhold,waitingorforwarded/diverted. 25 In this case both ends may share video simultaneously meaning that there is a possibility to have a bi directional flow of video (see the other partys video while I am also sharing video with him/her). The meaningisthatifauserisalreadysharingvideowiththeotherend,theotherusermaydecidetoalsoshare videosimultaneously,notthatthetwowaysvideosharecanstartsimultaneously.
23
Page 50 of151
RCSeAdvancedComms: Servicesandclientspecification When referring to bidirectional video share, we mean that once user A is sharing video withuserBandprovidetherightcoverageconditionsareinplace,userBcouldalsostart tosharevideowithAsimultaneously.Inthiscaseeachvideosharesessionisindependent andshouldbehandledseparately. Pleasenoteinthetablebeforeandforalltheservicesitisassumedthat: Thephoneisworkingadequately.Intheeventtheterminaldetectsanissuethat prevent one or more services fromoperating, the relevantcapabilities should be reportedasnotavailable. Thereisenoughbattery:Somephonesmaypreventusingsomeoralltheservices when the battery level achieves certain level. In this situation, basic and emergencyfunctionalityshouldbeprioritised. ThephoneisregisteredandisabletoaccessIMS/RCSecorenetworkandrelevant servers.
Forclarificationpurposesandinadditiontothepreviousones,thefollowingassumptions aremadefortheimageandvideosharecases: Boththesharingandreceivingendareinacall(CS)betweenthem Thecallisnotamultipartycall Thecallisnotonhold Thecallisnotwaiting Acallforwardordivertisnotinplace Inotherwords,therelevantimageandvideosharetagsdescribedinsection2.3.1.1SHALL beincludedonlyif: 1. theOPTIONSexchangehappenswhentheuserisonanactivecall,and, 2. the destination (sending OPTIONS) or the requester (receiving an OPTIONS messagewhichhastoberepliedwitharesponse)istheotherendoftheactivecall. Asaconsequenceoftheinformationpresentedabove,aRCSeclientwhichisregistered will at least support chat. Note that while capability exchange is reciprocal, User A and UserBscapabilitiesmaybedifferentandservicesshallbemadeavailableaccordingly(e.g. AmaysupportvideoencodeandBmaysupportdecode,butbothneedtobeunder3Gor betterdatacoveragefortheservicetowork). In addition to the information presented above, we should take into account that some terminalsdonotsupport2GDTM(dualtransfermode).Forthatdevicesandprovidethey areusinga2Gdatacoverage(meaningthatnoservicesareavailableduringthecall),the PSconnectionwillautomaticallydroponcetheyengageonaCScall.
2.7.1 CapabilityExtensions
ThedefaultsetofRCSecapabilitiesisdescribedinsection2.3.1.1(onepertagdescribed inTable11),however,giventheextensibilityoftheserviceframeworkfurthercapabilities may be added (i.e. following the proposal given in Table 12 or agreeing more common servicesandtheassociatedtagsinfutureversionsofthespecification).
Page 51 of151
2.7.2 IMstoreandforward
As presented in Table 5 (IM CAP ALWAYS ON), there is the possibility to configure the clienttoassumethattheMNOwillbeprovidingtheIMstoreandforwardfunctionality, whichbasicallyconsistonstoringthemessageswhicharesenttouserswhoareoffline(i.e. nodataconnectivityorphoneoff)atthetimethechatmessageissent. Ifthisparameterisenabled,thereisanimpactfromtheIMcapabilitywhichispresented totheuser. Asaconsequence,wehave4differenttypesofcontactsforIMcapability: ID Targeted contactisRCS eIMcapable? NO YES ProviderMNO supportsStore& Forward? N/A NO Targetedcontact isconnectedto thenetwork? Norelevant NO ImpactonstartingIM IMneverpossiblewith thatcontact Notpossibletostartan IMatthattime PossibletosendanIM thatwillbedelivered laterbytheStoreand Forwardserverassoon astheContactis connected IMispossibleand messagesare immediatelydelivered
1 2
YES
YES
NO
YES
Norelevant
YES
Table14.Storeandforwardpossiblescenarios
Thestoreandforwardfunctionalityandbehaviourontheclientiscontrolledbyacouple ofconfigurationparameters(seeTable5forfurtherreference): IMCAPALWAYSON: o When an operator implements store and forward, all its RCSe customers willhavetheIMCAPALWAYSONissettoenabled.ThismeansthatallRCS econtacts(currentlyregisteredornot)arepresentedwiththeIMserviceas available(3and4accordingtoTable14). o When store and forward is not implemented by the MNO, all its RCSe customerswillhavetheIMCAPALWAYSONconfigurationparameterisset todisabled(2and4accordingtoTable14). As a summary: IM CAP ALWAYS ON is enabled when store and forward is used, otherwiseitisdisabled Additionally and assuming IM CAP ALWAYS ON is enabled, there is an second parameter,IMWARNSF,whichcanbeusedtocontroltheUXbehaviour: Page 52 of151
RCSeAdvancedComms: Servicesandclientspecification o IfIMWARNSFparameterisenabled:Inscenarios3and4,theusershallbe awarethatmessagesdeliveredtounregistereduserswillbeonlydelivered oncetheotherpartyisbackonline(e.g.switchesthephoneonorgetsback incoverage). o If IM WARN SF parameter is disabled, there shall not be any visible differencebetweenscenarios3and4fromtheUXpointofview.Inother words, the user shall not be aware on whether the messages are being storedordirectlydeliveredtotheotherparty.
2.7.3 Videointeroperability
Aspresentedinsection2.7,thevideoshareserviceavailabilityismainlydependentonthe network coverage. This is based on the assumption that both ends (source and destination)sharetheabilityofhandlingacommonvideoformatandspecificprofile. InordertoguaranteetheinteroperabilityofallRCSeduringthevideosharescenario,all RCSe devices supporting the video share service shall, at least, support the following videoformat: Videoformat:H.264/MPEG4Part10//AVC(AdvancedVideoCoding) o H.264Profile:BaselineProfile(BP) o H.264Level:1b Please note that it is recommended to support additional video formats providing differentlevelsofqualityandtousetheminanadaptivefashiondependingbothonthe terminalstatusandthenetworkconditions/coverage. IncaseaRCSeterminalsupportsseveralprofiles,thefinalchoiceshouldbebasedinthe outcomeoftheSDPmedianegotiationwherebothends(senderandreceiver)willpresent thesupportedvideoformatsatthatparticularpointintime(i.e.takingeachdeviceand network/connectivitystatus).
2.8 RCS-e protocols

ThefollowingtablesummarisesthelistofprotocolsemployedbyRCSeclients.Itmustbe notedthatthechoicewillnotimpactMNOinteroperability: Protocolname Session initiation protocol(SIP) MediaSession RelayProtocol (MSRP) Description ClientIMScore signallingprotocol chatmessages,media (pictures)andfile exchangeprotocol Transport layer UDP/IPor TCP/IP TCP/IP Securetransport layer/protocol SIPoverTLSorIPSec
MSRPoverTLSorIPSec
Page 53 of151
RCSeAdvancedComms: Servicesandclientspecification Realtime protocol(RTP) Media(video)exchange UDP/IP SecureRTP(SRTP)26or IPSec
Table15.RCSerecommendedprotocols
ItisrecommendedthatRCSeclientssupportbothSIP/UDPandSIP/TCPasthechoiceof theSIPtransportprotocolsusedtotransportthesignallingdatabelongstoeachMNO. Regarding the impact of NAT traversal in the different protocols involved in RCSe, the followingconsiderationsshallbetakenintoaccount: RegardingSIPprotocol: o CRLF keepalive [IETFDRAFTSIPCOREKEEP]27support is MANDATORY when SIP/TCPorSIP/TLSisusedbytheRCSeclient. o STUNkeepalive[IETFDRAFTSIPCOREKEEP]supportisRECOMMENDEDwhen SIP/UDPisusedbytheRCSeclientasitallowsnetworkcapacityoptimization. o RCSeclientusingSIP/UDPandnotsupportingsipcorekeep: SHALL support symmetric signalling (i.e. IP/port used to send SIP messagesisthesameastheoneusedtoreceiveSIPmessages). SHALLperformTCPswitchoverforlargeSIPmessages. MSRPsessions,theRCSeclientSHALLsupport: [RFC6135]28 [IETFDRAFTSIMPLEMSRPSESSMATCH]29 Regarding NAT traversal of RTP sessions, the RCSe client should implement the mechanismdescribedinsection2.8.1.
The support of TLS based or IP Sec based protocols to secure the signalling and media exchanges is RECOMMENDED particularly for those scenarios where the data has to be carriedoveranetworkoutsidetheMNOdomain(i.e.WiFiaccess).Atthetimethisspecis published, this functionality is left as optional and how interoperability between RCSe clientandMNOcanbeachievedisleftforfurtherstudies.
2.8.1 RTPandNATtraversal
Aspresentedintheprevioussection,aRCSeclienthastoimplementseveralmechanisms to avoid the negative impact of NAT traversal, which can both occur when connecting over: PS:Mainlyduetothe scarceofIPv4publicaddressesandproxyingperformedat APNlevel,or,
26 27
SecureRTPasperIETFRFC3711[RCF3711]availableathttp://www.ietf.org/rfc/rfc3711.txt SipcorekeepfunctionalityisdescribedinthefollowingIETFdraft:http://tools.ietf.org/html/draftietf sipcorekeep12 28 TheAlternativeConnectionModelfortheMessageSessionRelayProtocol(MSRP)IETFRFCisavailableat http://tools.ietf.org/html//rfc6135. 29 SimpleMSRPseesmatchasdescribedinthefollowingIETFdraft:http://tools.ietf.org/html/draftietf simplemsrpsessmatch10
Page 54 of151
RCSeAdvancedComms: Servicesandclientspecification WiFi:Inthiscaseduetothefactthenetworktopologybetweentheaccesspoint andtheInternetmayvarybetweendeployments.
InordertocombatthenegativeeffectsofNATtraversalontheRTPprotocol,theRCSe clientshouldimplementthefollowingmechanisms: SHALL support a keepalive mechanism in order to open and maintain the NAT binding alive regardless of whether the media stream is currently inactive, send only, receiveonly or sendreceive. Possible standard keepalive mechanisms are STUNkeepalive(asper3GPPTS24.229)orempty(nopayload)RTPpacketwitha payloadtypeof20(asper3GPPTS24.229). SHALL use symmetric media (i.e. use the same port number for sending and receiving packets) as defined in [RFC4961]30mechanism which is summarized below: o When an invitation for video share is received and accepted, the 200 OK responsecontainsaSDPbodycontainingallthenecessaryfields(including thedestinationport)forthesendertosendtheRTPpackets. o Immediately after sending the 200 OK response, the receiver will send a keepalivepacketbacktothesendertosecurethemediapath: Thesourceportshallbeidenticaltotheoneincludedinthemfield oftheSDPpayloadinsidethe200OKresponse. Thedestinationportshallbeidenticaltotheoneincludedinthem fieldoftheSDPpayloadinsidetheSIPINVITEmessage. o Thesendershouldallowenoughtimeforthemediapathtobesecured.
PrivateIP (IPa) Public IP (IPm) PrivateIP (IPb)
UserA (sender)
IMSCore (Mediaproxy)
UserB (receiver)
SIPINVITE (SDPsourceport=A) 200OK (SDPdestport=P1)
SIPINVITE (SDPsourceport=P2) 200OK (SDPdestport=B) keepalive (Source:IPb:B,Dest:IPm:P2)
RTP(videosharedata) RTP(videosharedata) (Source:IPa:A,Dest:IPm:P1) (Source:IPm:P2,Dest:IPb:B) RTP(videosharedata) RTP(videosharedata) (Source:IPa:A,Dest:IPm:P1) (Source:IPm:P2,Dest:IPb:B) Figure19.RTPsymmetricmediapathestablishment
SHALLuseRTCP.
30
The symmetric RTP / RTP http://tools.ietf.org/html//rfc4961.
Control
Protocol
(RTCP)
IETF
RFC
is
available
at
Page 55 of151
RCSeAdvancedComms: Servicesandclientspecification Please note that for readability purposes, the procedures described in this section have notbeenincludedinthediagramscoveringvideosharefunctionalityinsection3.3.
2.9 Addressing and identities

2.9.1 Overview
Telephone numbers in the legacy address book must be usable (regardless of whether RCSecontactshavebeenenrichedornot)fortheidentificationofcontactsofincoming andoutgoingSIPrequests. Also,RCSeusers,especiallyinEnterprisesegments,maybeassignedanonMSISDNbased identity.TheRCSeclientwouldbeprovisionedwiththeappropriateSIPURIparameteras seeninTable5,leavingtheTELURIparameterempty. Consequently, a RCSe enabled terminal address book should also be able to store IMS URIsaspartofacontactdetails.
2.9.2 DeviceIncomingSIPRequest
2.9.2.1 From/PAssertedIdentity For device incoming SIP requests, the address(es) of the contact are, depending on the typeofrequest,providedasaURIinthebodyofarequestorcontainedinthePAsserted Identityand/ortheFromheaders.IfPAssertedIdentityispresent,theFromheaderwill beignored.TheonlyexceptionstothisrulearewhenthePAssertedIdentitymatchesthe one defined for the store and forward notifications or the one used for incoming group chat invitations, in which the Referredby header should be used to retrieve the originatinguserinstead. The receiving client will try to extract the contacts phone number out of the following typesofURIs: TEL URIs (for example tel:+1234578901, or tel:2345678901;phone context=<phonecontextvalue>) SIP URIs with a user=phone parameter, the contacts phone number will be provided in the user part (i.e. sip:+1234578901@operator.com;user=phone or sip:1234578901;phone context=<phonecontextvalue>@operator.com;user=phone) Once the MSISDN is extracted it will be matched against the phone number of the contactsstoredintheAddressBook.IfthereceivedURIisaSIPURIbutdoesnotcontain the user=phone parameter, the incoming identity should be checked against the IMS URIaddressofthecontactsintheaddressbookinstead. IncasemorethanonePAssertedIdentityisreceivedinthemessage,allidentitiesshallbe processeduntilamatchedcontactisfound.
Page 56 of151
2.9.3 DeviceOutgoingSIPRequest
2.9.3.1 Identificationofthetargetcontact IfthetargetcontactcontainsanIMSURIthevalueshallbeusedbytheRCSeclientwhen generating the outgoing request even if an MSISDN is also present for the contact. This appliestotheSIPRequestURIandtheToheader(asdefinedin[3GPPTS24.229])for1 1communication,aswellastotheURIsusedintherecipientlistincludedinoutgoingSIP requestsforgroupchat. In case no IMS URI is present the RCSe client shall use the telephone number (in local formatforexample0234578901orglobalformat+1234578901)setintheaddressbookor adialstringenteredbytheuser. Incaseofinternationalformattelephonenumber,thedeviceshouldsupportTELURI(for example tel:+12345678901) as defined in [RFC 3966] 31 and SIPURI (for example sip:+12345678901@domain;user=phone) with the user parameter set to "phone" as definedin[RFC3261]32.ThisshouldbeconfigurableonthedeviceaccordingtotheService Provider'srequirementsorconstraintsrelatedtonationalregulatoryframeworkofSIPSIP interconnection(MNOwillprovidethischoiceduringcustomization).Ifnoneoftheabove constraintsapply,theuseofTELURIisrecommendedsincethedomainnameoftheSIP URIisnotsignificant. In case of noninternational format telephone number, the RCSe client should support TELURIandSIPURI(theuserparametershouldbesetto"phone")withaphonecontext value set as defined in [TS 24.229] 33 for home local numbers (for example tel:0234578901;phonecontext=<homedomainname>). Like the international number case, whether a TELURI or a SIP URI is used should be configurable on the device according to the Service Provider's requirements or constraints related to national regulatoryframeworkofSIPSIPinterconnection.Ifnoneoftheaboveconstraintsapply, theuseofTELURIisrecommended. 2.9.3.2 SelfIdentificationtothenetworkandtheaddressedcontact: ForgeneratinganoutgoingrequesttheSIPURIorTELURItheRCSeclientshallsetthe FromheaderandthePPreferredIdentityheaderwiththeSIPorTELURIwhichhasbeen provisioned.IfbothSIPURIandTELURIareconfigured,TELURIshouldbeused. 2.9.3.3 Useralias The user shall be able to specify an alias or name to be used for RCSe services. This informationwillbesentwhenestablishingacommunicationtoanotherusersohecanget moreinformationthanjusttheMSISDNincasetheoriginatinguserisnotinthereceiver AddressBook.Thiscasewillprobablyverycommoninaonetomanygroupchat. ThisaliasinformationwillbesetintheFromheaderoftherequestandretrievedbythe receiver.
TheTelURIfortelephonenumbersIETFRFCisavailableathttp://tools.ietf.org/html//rfc3966. TheSIP:SessionInitiationProtocolIETFRFCisavailableathttp://tools.ietf.org/html//rfc3261. 33 3GPPTS24.229:IPmultimediacallcontrolprotocolbasedonSessionInitiationProtocol(SIP)andSession DescriptionProtocol(SDP);Stage3

32
31
Page 57 of151
RCSeAdvancedComms: Servicesandclientspecification When receiving a request, the RCSe client device shall follow the rules explained insection2.9.2.1andextracttheMSISDNorSIPURI.Inordertoavoidspamandidentity manipulation,thereceivershallchecktheidentityofthecallinguseragainsttheAddress Book.IftheuserisnotintheAddressBook,thealiasinformationmustbeusedthento providemoreinformationaboutthecallinguserbutclearlydisplayingintheUIthatthe identity is unchecked and it could be false. Otherwise the name of the contact in the addressbookshallbeusedinstead.
2.10 Data traffic and roaming considerations

Until a global roaming agreement on IP based services is agreed and implemented by MNOs, the RCSe IP traffic in roaming is going to be considered as standard data traffic andwillnotbedistinguishablebythedeviceorthevisitingnetworkfromotherInternet datatraffic. Inadditiontothis,manyofthemajorityofhandsetplatformsonlysupportoneAPNactive atthetime.Toovercomethesedifficultiesandallowthefinalusertohavegreatercontrol of the behaviour of the handset regarding data traffic, RCSe handsets will come configuredwithtwodifferentAPNs: InternetAPNwithRCSetrafficenabled RCSeonlyAPNwithnoInternetaccess
Theusershallbeableconfigureto allowordisallowRCSeand/orinternettrafficinthe handsetsettingswhenroamingaccordingtothefollowingalternatives: Datatraffic switch RCSeswitch APNtouse Comments RCSeclientshallnotregisteron theIMSnetwork.Whennot roaming,thisisoptionalanditis uptotheMNOtoshowthis option Standardconfiguration RCSeonlyconfiguration Nodataconfiguration
Enabled
Disabled
InternetAPN
Enabled Disabled Disabled
Enabled Enabled Disabled
InternetAPN RCSeonlyAPN none
Table16.APNconfigurationproposalfordatatrafficandroaming
Note the RCSe only APN is configured via the RCSE ONLY APN parameter presented in section2Table5. Thisapproachcanbeusednotonlyforroamingbuttoprotecttheuserfromunexpected charges. Therefore, an MNO can decide to display this setting permanently (covering homenetworkscenarios).Thebehaviourofwhethertoshowthesettingpermanentlyis drivenbytheconfigurationparameterENABLERCSESWITCH(seeTable5).Ifenabled,the settingispermanent.Ifdisabled,thesettingisonlyproposedduringroaming. Finallynotethatthedefaultconfiguration(e.g.bothInternetandRCSeenabled)shallbe aconfigurationoptionavailabletoMNOsduringdevicecustomization. Page 58 of151
2.10.1 Dataconnectionnotifications
Takingintoaccountboththeregulatoryframeworksapplyingtosomemarkets,itcouldbe necessarytonotifytheuserwhenaPSconnectionisgoingtobeinitiated.Fromthedata connectionnotificationpointofview,therearethreepossibleconfigurations: Setting neverconnect alwaysask

Terminalbehaviour connectiondisabled nopopup popup*:requestingconfirmationtogoonlineand informingaboutpossibledatacharges userhasthefollowingoptions:reject,confirmtoconnect onesortoswitchtoalwaysconnectandconnect whenuserconfirmstheconnectionisenabled
*Alternatively,ashortcuttothedevicedatasettings,togetherwithawarning thatdatachargesmightapply,ispresentedwheretheusermayenablethe connection. connectionenabled nopopup Table17.Dataconnectionnotificationoptions
alwaysconnect
Consistently with the configuration switches presented in the previous section (RCSe on/off, data on/off), an RCSe handset shall be able to apply the data connection notification options (described in Table 17) individually to each of the following connections:

Internet home: Standard data connection occurring within the MNO provider homenetwork. Internetroaming:Standarddataconnectionwhenroaming. RCSe home: Data connection required for RCSe occurring within the MNO providerhomenetwork. RCSeroaming:DataconnectionrequiredforRCSewhenroaming
As for the data connection switches presented in section 2.10, it is up to each MNO to decideduringcustomizationonwhether: a) Define the default settings (e.g. always connect for all home connections and alwaysaskforroamingones) b) Definewhetherthedataconnectionnotificationsettingsareshownaspartofthe handset configuration settings (i.e. the user is able to change the notification behaviour)instead.
2.11 Privacy considerations

Atthemomentthisversionofthespecificationispublished,theworktoputtogethera set of guidelines to address the user privacy issues associated to RCSe is not yet
Page 59 of151
RCSeAdvancedComms: Servicesandclientspecification completed.Weareincludingthissectiontosignaltheintentionofincludingtheoutcome ofthatworkinfuturerevisionsofthisspecification. As a first step and to allow commercialization in those countries with strict privacy regulations, the mechanisms presented in section 2.10 may be also used for privacy purposes,particularly,whentheRCSeswitchismadepermanentlyaccessibletotheuser (i.e. not only for roaming cases) via device (ENABLE RCSE SWITCH configuration parametersetto1;seeTable5forfurtherreference).
2.12 RCS-e and LTE

Theaimofthepresentsectionistogiveanoverviewofthepossibilitiestocomplement andintegrateLTEandRCSe. Pleasenotethatatthetimethisspecificationispublished,theworktointegrateLTEand RCSe is not completed, therefore, this section only contains references to those areas where the work has been completed leaving for future versions of the specification the remainingelementsforacompleteintegration.
2.12.1 LTEandVoiceoverLTE
LTE (Long Term Evolution) is a radio access network based on OFDM (Orthogonal Frequency Division Multiplexing) for the air interface. LTE has been developed in 3GPP (from Release 8 onwards). The key objective of the LTE is to enhance performance and efficiency(e.g.improvingdownlink/uplinkbitrates[Mbps],improvingdownlink/uplinkcell spectrumefficiency(bps/Hz/cell),reducingairinterfacelatency[ms],...). Voice over LTE (VoLTE) ([PDRIR.92]) addresses the support for PS based voice, voice supplementary services and SMS. VoLTE is complementary to RCS in terms of services, sincedealingwithvoiceservices. FinallyitshouldbenotedthatitisintendedforRCSetocomplyto[RCS4IR92ENDORS]34.
2.12.2 LTEcapabilitydiscoveryusingtheRCSe
AcoupleofOPTIONScapabilitytags(seesections2.3.1.1and2.3.1.2forfurtherreference on OPTIONS tags) have been introduced in RCSe to improve the LTE bearer and voice capabilities: Tag +g.3gpp.icsiref="urn%3Aurn7%3A3gpp service.ims.icsi.mmtel" Usage UsedtoindicatethataVoLTEcapable handsetisunderLTEcoverage35
Table18.SIPOPTIONStagproposalforLTE
RCS Release 4 Endorsement of GSMA IR.92 GSMA IMS Profile for Voice and SMS version 1.0 ([PRD IR.92]).Bothdocumentsareavailableatwww.gsmworld.com 35 Consistentlywiththedefinitionpresentinsection5.1.1.2.1of3GPPTS24.229
34
Page 60 of151
RCSeAdvancedComms: Servicesandclientspecification These tags are available for future use and may be used for general or service specific optimizationsalwaysinconjunctionandalignedwiththerelevantLTEspecifications.
2.12.3 LTEandVideosharefunctionality
VideoshareusedoverhighbandwidthconnectionssuchasLTEallowshighbitratebearers, thusallowingbetteruserexperiencee.g.whenusingalargescreen. An RCSe device shall support H.264 video codec with level 1.3 in order to provide 384/768 kbps video over an LTE bearer or over similar high bitrate bearer. Please note thatthisisanadditiontothemandatoryformatH.264profilebaselinewithlevel1b Assumption for use of high bitrate bearer is that connectivity and video parts of both terminalssupportitandhaveLTEorotherhighbitratebroadbandaccess;otherwisethe video bitrate will be reduced to the level 1b (as presented in section 2.7.3) in order to assurecompatibility.
2.13 End User Confirmation Requests

There are several scenarios where the MNO requires an End User approval for some specificpurpose,likeforexampleacceptingtheTermsandConditionsforaService.Upto now there was not a standard mechanism that allows the MNO to directly ask the End Userinthiskindofsituations. TheRCSespecificationprovidesaframeworkthatwillallowtheMNOtoinformtheEnd Useraboutacertainsituationbyopeningadialoginthehandsetterminalpresentingall theavailableinformationandasktheusertoconfirmordeclinetheproposedrequest. The end user confirmation request is implemented using an SIP MESSAGE method containingaXMLpayloadoftypeapplication/enduserconfirmationrequest+xmlthatwill besentbytheMNOservingtheEndUsertohisRCSehandset/client. UponthereceptionoftheSIPMESSAGE,theenduserterminalwillcheckthePAsserted IdentityoftheincomingmessageandmatchitagainsttheconfiguredURIfortheservice asdefinedinTable5andextracttherequestinformationfromtheXMLpayloadbody.A dialog or notification will be displayed to the End User (UX dependant) showing the confirmationrequestandrelatedinformation. TheEndUserconfirmationresponsewillbeencapsulatedinanXMLbodywithapayload of type application/enduserconfirmationresponse+xml and returned either in the SIP MESSAGEresponsebacktotheMNOorinanewSIPMESSAGE Theinformationcontainedintheenduserconfirmationrequestisthefollowing id:Uniqueidentifieroftherequest. type: Determines the behaviour of the receiving handset. It can take one of the followingtwovalues: o volatile,theanswershallbereturnedinsidethe200OKresponse.IftheSIP INFO message times out without end user input, the request will be discarded.
Page 61 of151
RCSeAdvancedComms: Servicesandclientspecification o persistent, the answer shall be returned inside of a new SIP MESSAGE request.Theconfirmationrequestdoesnottimeout. pin:Determineswhetherapinisrequestedtotheenduser.Itcantakeoneofthe following two values: true or false. If the attribute is not present it shall be considered as false. This pin request can be used to add a higher degree of confirmationandcanbeusedtoallowcertainoperationslikeparentalcontrolfor example. Subject:texttobedisplayedasnotificationordialogtitle Text:texttobedisplayedasbodyofthedialog.
Several Subject or Text nodes can be present in the xml body to be able to support multiplelanguages.Incasemoreofoneelementispresentedalanguage(lang)attribute must be present with the two letter language code according to the ISO 6391. RCSe clients shall check the language attribute and display the text data of the element that matches the current language used by the user. In case that there is no language matchingtheuserone,thefirstnodeofSubjectandTextshallbeused. If the type of the confirmation request is persistent the MNO can send an optional acknowledgementmessageofthetransactionbacktotheuserwithawelcomemessage, an error message or further instructions. This acknowledgement message will be encapsulated in an XML body with a payload of type application/enduserconfirmation ack+xmlandreturnedinthe200OKbodyoftheconfirmationSIPMESSAGE. The following table specifies the xsd schema of the xml payload for the end user confirmationrequest:
<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> <xs:element name="EndUserConfirmationRequest"> <xs:complexType> <xs:sequence> <xs:element ref="Subject" maxOccurs="unbounded"/> <xs:element ref="Text" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="id" use="required"/> <xs:attribute name="type" use="required"/> <xs:attribute name="pin"/> </xs:complexType> </xs:element> <xs:element name="Subject"> <xs:complexType> <xs:attribute name="lang"/> </xs:complexType> </xs:element> <xs:element name="Text"> <xs:complexType> <xs:attribute name="lang"/> </xs:complexType> </xs:element> </xs:schema> Table19.EndUserConfirmationRequestXSD
Page 62 of151
RCSeAdvancedComms: Servicesandclientspecification Theinformationcontainedintheenduserconfirmationresponseisthefollowing id:Uniqueidentifieroftherequest. value:withtheenduserconfirmation.Itcantakeoneofthefollowingtwovalues acceptordecline.

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> <xs:element name="EndUserConfirmationResponse"> <xs:complexType> <xs:attribute name="id" use="required"/> <xs:attribute name="value" use="required"/> <xs:attribute name="pin" use="optional"/> </xs:complexType> </xs:element> </xs:schema> Table20.EndUserConfirmationResponseXSD
Theinformationcontainedintheenduseracknowledgeresponseisthefollowing id:Uniqueidentifieroftherequest. status:withtheenduserconfirmation.Itcantakeoneofthefollowingtwovalues okorerror. subject:texttobedisplayedasnotificationordialogtitle text:texttobedisplayedasbodyofthedialog.

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> <xs:element name="EndUserConfirmationAck"> <xs:complexType> <xs:sequence> <xs:element ref="Subject" maxOccurs="unbounded"/> <xs:element ref="Text" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="id" use="required"/> <xs:attribute name="status" use="required"/> </xs:complexType> </xs:element> <xs:element name="Subject"> <xs:complexType> <xs:attribute name="lang"/> </xs:complexType> </xs:element> <xs:element name="Text"> <xs:complexType> <xs:attribute name="lang"/> </xs:complexType> </xs:element> </xs:schema> Table21.EndUserConfirmationAcknowledgementXSD
Page 63 of151
2.13.1 ExampleUC1:Acceptingtermsandconditions
UEUser/ClientA
IMS UI Core A new service is available in the network for the user that requires the user to accept Terms and Conditions. SIPMESSAGE (XML) 200OK The user accepts the conditions SIPMESSAGE(XML) 200OK(optionalXML) Figure20.TermsandConditionUCexample
Client Logic
Service AS
Page 64 of151
2.13.2 ExampleUC2:AcceptingExtraCharges
UEUser/ClientA UI Client Logic
The user starts a file transfer
IMS Core
IM AS
UserB
TheIMserverdetectsa special condition that will cause an extra charge If the file transfer is completed andaskfortheenduser confirmation
SIPINVITE(SDP) 100Trying SIPMESSAGE (XML) 100Trying
The user accepts the extracharge
200OK(XML)
The IM server continues with thefiletransferestablishment.
Figure21.ExtraChargeUCexample
Page 65 of151
2.14 GRUU and multidevice support

RCSe clients and terminals SHALL support GRUU as specified in [RFC5627]36. When the user agent generates a REGISTER request (initial or refresh), it SHALL include the Supportedheaderfieldintherequest.ThevalueofthatheaderfieldSHALLinclude"gruu" asoneoftheoptiontags.ThisalertstheregistrarforthedomainthattheUAsupportsthe GRUUmechanism. IneachcontactincludedintheREGISTERrequest,theclientSHALLincludea"sip.instance" tag,whosevalueistheinstanceIDthatidentifiestheuseragentinstancebeingregistered. To avoid potential privacy issues, IMEI SHALL NOT be used as the deviceid value of sip.instance; instead this deviceidvalue mustbe an UUID (generated by the handset as specifiedin[RFC4122]37)andmustnotbemodifiedovertimeIftheREGISTERresponseis a2xx,eachContactheaderfieldmaycontaina"pubgruu"conveyingthepublicGRUUfor the user agent instance. Please note that the GRUU support is not mandatory for the network operators so user agents shall be ready to not receive any GRUU from the registrar. If a user agent obtains GRUUs from the registrar, it shall use the public GRUU as a URI parameter for the user agent in nonREGISTER requests and responses that it emits, for example,anINVITErequestand200OKresponse. IfauseragentdoesnotobtainaGRUUfromtheregistrar,itshallincludethesip.instance feature tag in the Contact header with the same deviceid value in any nonREGISTER requestandresponsesthatitemits.PleasenotethatthedestinationUAshouldfollowthe standard procedure for tags and move them from the contact to acceptcontact header whenissuingresponsesorsignalling(i.e.messagenotificationsassociatedtoanIM/chat invitation)associatedtotheinitialrequest. Pleasenotethatforsimplificationandbecauselongtermstandard[RFC5627]36approach is preferred, the diagrams contained in ANNEX C show the behaviour in a network supportingpubgruugeneration.Thediagramsforanetworksupportingthesip.instance tagonly,wouldbeequivalentbutchangingtherelevantmechanismtocarrythedeviceID (sip.instanceinsteadpubgruu).
TheObtainingandUsingGloballyRoutableUserAgentURIs(GRUUs)intheSessionInitiationProtocol(SIP) IETFRFCisavailableathttp://tools.ietf.org/html//rfc5627.Pleasenotethisspecalsorefersandincorporate partsofIETFRFC5626http://tools.ietf.org/html//rfc5626. 37 The Universally Unique IDentifier (UUID) URN Namespace IETF RFC is available at http://tools.ietf.org/html//rfc4122.
36
Page 66 of151
3. RCS-e sequence and UX diagrams

The user must be able to access RCSe services from the following terminal UI entry points: Address book and calllog: The user should be able to access the IM/chat and file transferservices.Notethefiletransferiscombinedwithchatonthereceivertocreate acommunicationcontext(i.e.thereceiverwantstoclarifywhythesenderissharing thatfile).Thechatsessionwontstartuntilthereceiversendsthefirstmessage,soitis possibletoacceptthefilewithoutchatting. In addition to this, the first view of the address book shall clearly identify the RCSe capablecontactswithaRCSeflag. Chatapplication:Theusershouldbeabletoaccesschatdirectlyfromtheapplication list. In this case the user can access either onetoone or, optionally, multichat (selecting/inviting more than one user). The user can also access to the chat history andcontinueapreviouschat. File browser, media gallery andcamera application: The user can access file transfer service. Note the file transfer is combined with chat at UX layer on the receiver to createacommunicationcontext(e.g.thereceiverwantstoclarifywhythesenderis sharingthatfile).Althoughoncetheincomingfileisacceptedthetransferispresented onachatwindowonthereceiverside,thechatsessionwontstartuntilthereceiver sendsthefirstmessage. Chatwindow:Itispossibletoaggregateanewcontact(s)toanexistingchatsession.In addition to this, file transfer is also available in onetoone chat. Although from the protocolpointofview,itisnecessarytohandleanewSIPinvitationandMSRPtransfer (i.e.filetransferoccursinaseparateMSRPcontext,notintheoneusedforchat),from the UX point of view, the communication context is already established so it is not necessarytoimplementanyadditionalactions. Callscreen:Videoandimagetransfer(livevideo,storedvideoorpicture).Pleasenote thecommunicationcontextisalreadyestablishedsoitisnotnecessarytoimplement anyadditionalactions. Finally,itshouldbenotedthatapreconditiontoprovideaccesstotheRCSefunctionality should be that all the mandatory parametersdescribed in section 2.1 (Table 5) must be correctly configured. In the case any of the parameters is not configured or configured with an unexpected value, the RCSe functionality should be disabled and in any case presented or accessible to the user (i.e. the phone behaves as it would be a nonRCSe enabledphoneandallRCSespecificUXelementsarenolongerpresentedtotheuser).
Page 67 of151
3.1 Access to RCS-e services through address book or call-log interaction

Theaddressbook(andtoextendthecalllogwindowasanalternativeforuserswhohave beenrecentlyphoned)isthecentrepiecetoaccessallservices. Fromtheaddressbook/calllogtheuserhasaccesstothefollowingservices: The user can identify which services are available for each contact. When a contactisselected,theservicecapabilityisupdatedviaSIPOPTIONStoprovidethe current,realtime,statusforthecontact. Ifavailable,theusercanstartachat Ifavailable,theusercanstartafiletransfer
3.1.1 Generalassumptions
In the following sections we will be showing the relevant chat message flows and reference user experience (UX). Please note that the following assumptions have been made: For simplicity, the internal mobile network interactions are omitted in the diagramsshowedinthefollowingsections.
Page 68 of151
3.1.2 Capabilitiesupdateprocess
The capabilities update process is described in the following diagram. In this case the contact(userB)isaRCSecontactwhichisregistered.Pleasenotethecapabilitiesareonly updatedon1to1chats.Inmultichatsessions,therearenootherservicesavailableand the ultimately responsibility to maintain and report the status of the session is the IM applicationserver. UEUser/ClientA UEUser/ClientB Client Client IMS UI UI Logic Logic Core The user enters in the phone book looking for acontact Theuserselectsacontact.AssoonasthishappensandprovidedthecontactisanRCS ecustomer(informationobtainedviaSUBSCRIBEpolling),thefollowingprocesstake place: 1) Thecachedcapabilitiesareshown 2) Anoptionsmessageissenttotheotherusertoupdateitscapabilities SIPOPTIONS(capabilitiesA) The capabilities for user A are updated in the otherend SIP200OK(capabilitiesB) Oncetheoptionsmessagearrivesandtaking intoaccounttheupdatedcapabilities,thelist ofAdvancedServicesisupdated. In this case file transfer was not available, howeveritisnowshownasavailable
Figure22.Addressbook:Capabilitiesupdate
Page 69 of151
RCSeAdvancedComms: Servicesandclientspecification IfUserBiseithernotaRCSeuseroritisnotregistered,thenetworkprovidesaresponse to the OPTIONS message (404 NOT FOUND, 480 TEMPORARILY UNAVAILABLE/408 REQUESTTIMEOUTrespectively;pleaserefertosection2.3.1forfurtherreference).Inthis case,theUserAsclientassumesthatnoservicesareavailabletocommunicatewithUser B38. UEUser/ClientA UEUser/ClientB Client Client IMS UI UI Logic Logic Core The user enters in the phone book looking for acontact Theuserselectsacontact.AssoonasthishappensandprovidedthecontactisanRCS ecustomer(informationobtainedviaSUBSCRIBEpolling),thefollowingprocesstake place: 1) The list of services based on default capabilities (SUBSCRIBE polling) are displayed. The services which are not available are displayed in grey (like filetransferinthiscase) 2) Anoptionsmessageissenttotheotherusertoupdateitscapabilities SIPOPTIONS(capabilitiesA) SIP480TEMPORARILYUNAVAILABLE/SIP408REQUEST TIMEOUT Because the OPTIONS message fails, the services are listed as not available (greyedout)
Figure23.Addressbook:Capabilitiesupdate(II)
ItshouldbenotedthatinthiscaseifIMCAPALWAYSON(seeTable3)isenabled,theIM/chatshouldstill bereportedtotheuserasavailableeventheotherendisnotregistered.
38
Page 70 of151
3.2 IM/chat service

The IM service enables users to exchange messages between one or more users instantaneously.Chatisabaselineserviceavailabletoanyregistereduser.
RCSeIM(Chat)isabaselineservice,availabletoanyregistereduser,using[RCS2OMA SIMPLEENDORS]39asaspecificationbasis.Asnewoptionalfeaturesareintroduced(e.g. store and forward, "displayed" notification), some adjustments, clarifications or modifications need to be brought to [RCS2OMASIMPLEENDORS]39. The delta between RCSRelease2IMandRCSeIMarehighlightedinsection3.2.2.
3.2.2 DeltabetweenRCSeandRCSRelease2ontheIMfunctionality
3.2.2.1 FunctionalLevel ThefollowingoptionalnewfeaturesareintroducedinRCSe: storeandforward The deployment of this feature is at the MNO's discretion. This feature requires an IM servertostoreamessagewhenthedestinationuserisnotonlineandsendittotheuser whenhegoesonlineagain(i.e.storeandforward). "displayed"messagedisposition Thisnewdispositionallowsthesenderofamessagetobenotifiedwhenthismessagehas beendisplayedonadeviceofthereceivinguser. Notethatthisnotificationcannotcertifythattherecipienthasactuallyreadthemessage, itcanonlyindicatethatthemessagehasbeendisplayedontherecipient'sterminalUI. LocalBlackList Theterminal/ClientshallsupportalocallystoredIMBlackList.Basicguidanceisprovided insection3.2.4.1. Conversationhistory The terminal/Client shall support a locally stored conversation. The implementation detailsarenotyetcoveredinthisversionofthespecification. UserAlias Auserdefinednamecanbesentwhenestablishingacommunicationwithanotheruser. 3.2.2.2 Technical/ProtocolLevel ComparedtoRCSRelease2,inordertosupportstoreandforwardandmessage disposition,RCSeadds:
39
RCSRelease2EndorsementofOMASIP/SIMPLEIM1.0v2.0availableatwww.gsmworld.com
Page 71 of151
RCSeAdvancedComms: Servicesandclientspecification Supportof[RFC5438]40
RCSe relies on the support of Instant Message Disposition Notification (IMDN) as defined in [RFC5438]40 to request and forward dispositions of all the exchanged messages. The introduction of these concepts brings modification in the following requests comparedwithRCSRelease2: SIPINVITE o When an IM session is initiated by a Client, the SIP INVITE, still has to convey the message in the "subject" Header. In addition in RCSe, the message has to be replicated in a CPIM/IMDN4142wrapper including the DateTime; MessageID and DispositionNotification header fields. The deviceIDshallbecarriedusingthemechanismsdescribedinsection2.14. o To support the PUSH of stored messages by the store and forward IM Server, the SIP INVITE has to carry a wellknown URI uniquely identifying the store and forward service in the PAssertedIdentity header to allow theClienttoidentifythisspecialrequest(aswellastoassertfortheClient that the request comesfrom a trusted server). In that case, the "subject" headershallnotbeinterpretedbytheClientasamessage.Notethatthe IMServermayusethe"subject"headertocarryotherinformationsuchas thenumberofstoredmessages. o WhenanIMASisdeliveringstorednotificationswiththeaimofsignalling the client that the session has to be autoaccepted, the passertedid headerissettoaknownvalue(rcsestandfw@<domain>). o GRUU(GRUUpublicidentities,pubgruu,aspresentedinsection2.14)will be used to support the Autoacceptance of PUSH of stored notifications. Only the client whose device identifier matches the pubgruu value is Deviceidentificationusingthemechanismsdescribedinsection2.14. Messageidentificationforallmessages(includingthoseconveyedintheSIPINVITE andnotificationsdeliveredviaSIPMESSAGE) AutoacceptanceofstoreandforwardIMServerPUSHofstorednotifications storeandforwardIMServerPUSHofstoredmessages Messagedeliveryanddisplayednotifications
Onlythedevicewhichhassenttherelevantmessageshallacceptthenotification.
The Instant Message Disposition Notification (IMDN) IETF RFC is available at http://tools.ietf.org/html//rfc5438. 41 ItshouldbenotedthataSIPINVITEcarryingaCPIM/IMDNwillindeedhaveamultipartbodybecausea SDPconfigurationisstillrequired. 42 TheCPIM/IMDNwrappershouldbeUTF8encodedtoavoidanypotentialinternationalizationissues.
40
Page 72 of151
RCSeAdvancedComms: Servicesandclientspecification allowed to accept the session. This new request shall also use the well knownURIidentifierinthePAssertedIdentity(rcsestandfw@<domain>)43. SIPMESSAGE RCSereliesonSIPMESSAGErequeststocarrydeliverynotificationsofmessagessent prior the establishment of a media session. Again, the SIP MESSAGE shall carry a CPIM/IMDN42 wrapper including the DateTime; MessageID, DispositionNotification headerfields.Inadditiontothis,itshouldalsocontainthedeliverynotificationfieldto confirm the reception of the message by the other end. The deviceID shall also be transportedbutprotocoldetailsarenotyetdefinedinthisversionofthespecification. The AcceptContact header of the SIP MESSAGE used for IMDN shall carry the +g.oma.sipim feature tag 44 . Again, The deviceID shall be carried using the mechanismsdescribedinsection2.14. TheuseofSIPMESSAGEforPagerModemessagesisstillnotsupported(asitisnot supportedinRCSRelease2). MSRPSEND In RCSe, all messages (IM) are conveyed in CPIM/IMDN42 wrappers,which is strictly forbiddeninRCSRelease2. Whenapplicable,theseMSRPSENDrequestswithCPIM/IMDN42wrappersareusedby the sender to request IMDN 'delivered' and displayed notifications and by the receivertoprovidetheIMDNsamenotifications. Finally,inordertosupporttheuseofaliases,thelimitationaddedin[RCS_IMENDORSE]39 fortheuseofdisplaynameareremovedinRCSe. 3.2.2.3 Deliverynotifications Therearetwopossiblescenariosthatshouldbeconsidered: 1. Delivery notifications associated to messages that have been delivered before a MSRPsessionhasbeenestablished In this case, the mechanism which the receivers client shall use is to send the notification using SIP MESSAGE. More in details, the subject of the message is irrelevanthowevertheCPIM/IMDN42wrappershouldcarrythesamemsgIDcontained in the original message plus an delivered notification as described in [RFC5438] 40 section7.2.1.1. 2. Delivery notifications associated to messages that have been delivered after a MSRPsessionhasbeenestablished
Consequently,thercsestandfw@<domain>valuebecomesreservedandcannotbeusedbyanyidentity. This ensures that initial filter criteria already in place in GSMA RCS R1/R2/R3 environments will route theseSIPMESSAGEstotheOMASIMPLEIMserver.
44
43
Page 73 of151
RCSeAdvancedComms: Servicesandclientspecification In this case, the MSRP SEND message carrying a CPIM/IMDN42 wrapper with a delivered notification as described in [RFC5438]40 section 7.2.1.1 and presented beforeinthissection.AgaintheoriginalmessageCPIM/IMDN42msgidshallbecarried toidentifythemessagethisnotificationisassociatedto. Thesenderclientsideshallsupportbothscenarios,processthedeliverynotificationand displaythisinformationtotheuser.Therecommendationistoshowthisinformationonly withintheIMwindowwithoutaneedforapopuporinformationmessagewhentheuser isoutsidetheIMapplication. Please note that in multidevice scenarios, when a session is set up and delivery notificationsstarttoarriveforstoredmessages,theIMserverneedstoensurethatthey arenotforwardedtothecurrentdeviceintheIMsessionifthatparticipantisnottheright one. 3.2.2.4 Displaynotifications It should be noted that due to privacy issues, the displayed notification is optional meaning the user (receiver) shall have access to a configuration parameter to enable or disablethisnotificationviaUI. Display notifications are always carried using the MSRP SEND message, with a CPIM/IMDN42 wrapper carrying a displayed notification as described in [RFC5438]40 (section 7.2.1.2). Again the original message CPIM/IMDN42 msgid shall be carried to identifythemessagethisnotificationisassociatedto.
3.2.3 Clientassumptions
In the following sections we will be showing the relevant chat message flows and reference user experience (UX). Please note that the following assumptions have been made: For simplicity, the internal mobile network interactions are omitted in the diagramsshowedinthefollowingsections. Each MNO MAY deploy an IM Server (NB IM server is optional in RCSe specifications),tohandleallmessagesfromitscustomers. Priortothechat,theuseraccesseditsaddressbookorIM/chatapplicationtostart the communication. As described before, while these actions are performed an OPTIONS message is sent to doublecheck the available capabilities. In the following diagrams we are assuming that this exchange (OPTIONS and response) have already taken place, and therefore, both ends are aware of the capabilities and, consequently, the available RCSe services. If that is not the case, the OPTIONSmessageshouldbesentatthesametimethechatisbeingsetup. AlltheIMserviceexchangespresentedinthisdocumentfollowtheRCSRelease2 GSMAspecification[RCS2OMASIMPLEENDORS]39regardingclientterminalswith thefollowingdifferences: o Procedures have been introduced to inform the sender about the delivery statusofanIMsentbeforethesessionisestablished(i.e.IMintheSubject headerofaSIPINVITE).TheseproceduresarederivedfromInstantMessage Page 74 of151
RCSeAdvancedComms: Servicesandclientspecification Disposition Notification (IMDN for short) [RFC5438]40 and adapted to the contextofsessionmodeinstantmessaging. The terminal UI must be implemented in a way that the user can clearly distinguishifthemessagehasbeensent(butnotyetreceived),received,or displayed.Inaddition,thetimethemessagewasoriginallysentshallbealso presented. Procedures, based on the IMDN disposition 'displayed' have been introducedatthesendersidetorequest'displayed'notificationsandatthe receiversidetoprovide'displayed'notifications. AStoreandForwardfunctionalitycanbeusedinIMServer.Theprocedures followedbytheStoreandForwardfunctionalityofanIMServerarecovered inANNEXB. Procedures for Multidevice support with Store and Forward mode have been introduced in order to ensure consistent delivery of deferred delivered/displayednotificationstotheintendeddevice.
MNOsupportofthestoreandforwardfunctionalityisoptionalinRCSe.ToallowaMNO to provide store and forward functionality to its customers even in cases where the IM session is established toward an MNO that doesn't support store and forward, the messagesmaybestoredinthesendersIMserver. FromtheUXexperiencepointofview,therearethreepossibleentrypointstothisservice:
Figure24.ReferenceUXforaccessingchatfromaddressbook/calllog
Addressbook/Calllog:chatcanbeinitiatedtoanyRCSecontactwithIMcapability asdescribedin3.2.2.1.
IM/Chatapplication:ThereshouldbeadedicatedIM/chatapplicationentrypoint inthephonemenutaskorientedinitiation.Thisapplicationwillprovideaccess tothechathistoryandgivesthepossibilitytostartanewchat.
Page 75 of151
Figure25.ReferenceUXforstartingachatfromtheIM/chatapplication
Once the IM/chat application is opened, the user will be presented with the complete list of RCSe contacts with IM capability. Contacts which are currently notregisteredwillbeshownornotdependingontheIMstoreandforwardpolicy chosenbytheMNO. Inadditiontothestartanewchatfunctionality,theIM/chatapplicationallows theusertobrowsethechathistory,bothonetooneandonetomanysessions:
Figure26.ReferenceUXforstartingchatfromtheIM/chatapplicationhistory
Filetransfer(receiver):Whentransferringafileandwiththeaimofestablishinga communicationcontextforthetransfer(e.g.thereceivermaywanttoknowwhy thesenderissharingthatfile)andafterthetransferhasbeenaccepted,thefile transfer is presented to the receiver as a chat UX with a file being transferred. Pleasenotethatatthetimethefileispresented,thechatsessionisnotstarted; thechatsessionwillonlystartwhenifthereceiversendsachatmessagebackto thesender.
Page 76 of151
Figure27.ReferenceUXfiletransferonthereceiverside
Pleasenotesection3.4coverstheRCSefiletransferserviceindetail.
3.2.4 1to1Chat
A1to1ChatisamessageexchangebetweentwoRCSeusers.Pleasenotethatwherethe specificationdescribestheuserinterface,itshouldbetakenasguidance. 3.2.4.1 Initiatingachat ARCSeuser(A)initiatesachatbyselectingoneofhiscontacts(B)fromtheAddressBook orIM/chatapplicationinhismobilephone,orintheContactListintheBroadbandAccess PCclient. DeviceA(eithermobileorPC)willsendaqueryfortherealtimecapabilitiesofcontactB to ensure the IM service is available for that user at that time. If B is not available and there is no IM store and forward server on A's side and B's side, or if an answer to the queryisnotreceivedinlessthanatimelapse(lefttoOEMUserExperiencecriteria),then thecontactwillbeshownasNotavailableforaChatsession,andSMSservicecouldbe offeredasmessagingoption.OncetheavailabilityoftheIMserviceisensuredendtoend andtheuserperformstheappropriateUIactionsonthedevice,amessagecomposerand anemptychatwindowwillbeopened. WhenuserAtypesthefirstmessageandpressestheSendbutton,deviceAwillinitiate an IM session invitation toward B (for multidevice scenario see Multidevice handling in section 3.2.4.12). The IM session invitation is initiated according to the rules and procedures of [RCS2OMASIMPLEENDORS]39 except that the message should be duplicated in a CPIM/IMDN42 wrapper including the headers requesting an IMDN accordingtodeviceA(ifIMstoreandforwardisenabledontheIMapplicationserverand isabletotherulesandprocedureof[RFC5438]40,seesection3.2.4.11). When the device B receives IM session invitation, it will automatically send a SIP 180 answertowardA(ifsomekindofspamorblacklistisimplementedonthedeviceanduser Aisintheblacklist,theinvitationisrejectedandthemessageisputina'spam'folder).If the received IM session invitation contains an IMDN requesting 'delivered' notification, the device will send back a SIP MESSAGE containing the IMDN indicating successful deliveryofthemessagesentbyAaccordingtotherulesandprocedureof[RFC5438]40.
Page 77 of151
RCSeAdvancedComms: Servicesandclientspecification InthesideB,anotification(UIdependant)willbedisplayedondevicetoinformaboutthe incomingmessage.Theuserwillbeabletoreadthemessageandgotothechatwindow toanswerthemessage. User A can type additional messages before the chat is answered, i.e. before the IM sessionisestablished.TheadditionalIMsessioninvitationsarehandledaccordingtothe rules and procedures of [RCS2OMASIMPLEENDORS]39 except that the IMDN for 'delivered'statusisrequestedandsentsimilarlytothefirstsessioninvitation.OnB'sside, anotificationmaybedisplayedforeachreceivedmessage(UIdependant). 3.2.4.2 Answeringachat When B's device detects user activity relevant to the consumption of the message containedintheinvitation(e.g.clickonapopuptogototheIMwindow)the1to1 chatisestablishedaccordingtotherulesandprocedureof[RCS2OMASIMPLEENDORS]39. At this point an MSRP session is established between the two devices. If the IM session invitation from A contained an IMDN requesting 'displayed' notification, B generates an MSRPSENDrequesttowardAthatcontainstheIMDN'displayed'statusforthemessage receivedfromA. Theruleandprocedureof[RCS2OMASIMPLEENDORS]39arefollowedtohandlethecase where multiple IM sessions from A are pending on B's side. I.e. the last received IM session is established and the other pending sessions are answered with a 603 DECLINE response.Insuchcases,iftheIMsessioninvitationsfromAcontainedanIMDNrequesting 'displayed' notification, B generates an MSRP SEND request toward A that contains the IMDN'displayed'statusforeachmessagereceivedfromA 3.2.4.3 Messagesexchangedinanestablishedchat AslongasthisIMsessionisestablished,furthermessagesexchangedbetweenAandBare transported in the MSRP session according to the rules and procedure of [RCS2OMA SIMPLEENDORS]39exceptthat,forthereceivedMSRPSENDrequestscontaininganIMDN 'displayed'anddeliveredrequest,whentheusermessageisdeliveredordisplayed,the receivingdevicemustgenerateandMSRPSENDrequestcontainingtheIMDNstatus. 3.2.4.4 Displayandlocalstorage Allthemessageswillbestoredinthedevice,togetherwithsomekindoftimeindication andanappropriateindicationofthepartthatsenteachone. Intheusersdevice,alltheconversationsheldwiththesamecontactwillbedisplayedina singlethread,orderingstoredmessagesonatimelinebasis. Whenstoragelimitisreached,deletionshouldhappenonaFIFOqueuepolicy.Itisopen to OEM criteria how to implement other optin deletion mechanisms (e.g., ask always, deletealways,deleteanyconversation/messagefromspecificcontacts). 3.2.4.5 Leavingthechatcomposingwindow Oncea1to1chatisestablishedanyofthetwouserscanleavethecomposingwindow without closing the chat. For example, a user could move to his mobile home screen to checkanincomingemail,ormakeaphonecall. Page 78 of151
RCSeAdvancedComms: Servicesandclientspecification Whilethechatcomposingwindowisnotshown(thatis,itisnottheforegroundwindow) any incoming message corresponding to that chat will trigger a status notification (UI dependant)sotheuserisawareofthenewmessageand,ifhechoosesso,getbacktothe chatcomposingwindowtoanswerit. Also, the user could decide to get back to the chat composing window and send a new message without receiving one. The user would be able to do that via the IM/chat application, which will display the ongoing chats, or via the Address Book by clicking on thecontactwithwhomhehasthechatsessionopened. Inbothcases,whentheusergetsbackstothechatcomposingwindow,allthemessages willbedisplayed. 3.2.4.6 IsComposingnotification When any user starts typing in the chat composition window, an Is Composing notificationwillbesenttotheotheruser.HisUIwillthendisplayanindicationinthechat composingwindowtoindicateit(UIdependant). The Is Composing indication will be removed from the UI when a new message is received, when a timeout expires without receiving a new message, or when a new Is Composingnotificationarrives. The"isComposing"notificationishandledaccordingtotherulesandprocedureof[RCS2 OMASIMPLEENDORS]39 3.2.4.7 Closingachat/Reopeningachat AnyofthetwouserscanclosehisIMsessionassociatedwithanestablishedchat.Thiscan bedonefromthechatcomposingwindoworintheIM/chatapplication. Theuserwouldbeabletoreopenthechathowevertheresultingactionatprotocollevel woulddependonwhethertheIMsessionisstillopenornot. ClosingtheIMsessionwillnotbenotifiedtotheremoteuserinthechat.Thesessionis terminated, therefore, if the remote user sends a message, a process similar to the initiationofachatisperformedasdescribedin3.2.4.1. 3.2.4.8 Chatinactivitytimeout When a device or the network detects that therewas no activity in a chat for a configurableperiodoftime,itwillclosetheestablishedIM. 3.2.4.9 Chatabnormalinterruption IfauserinachatsuffersanabnormalterminationoftheIMsession,forexamplelossof coverage,itwillbeconsideredasithehadclosedthechatandthemechanismsspecified in section 3.2.4.7 (closing a chat) will apply, but in this case the Send button will be disabled. In temporary interruption cases, for example the mobile phone gets network coverage again, the chat window will be enabled again and the reopening chat mechanism explainedinsection3.2.4.7willbeavailable.
Page 79 of151
RCSeAdvancedComms: Servicesandclientspecification 3.2.4.10 ReOpeningachat Anoldchatconversationcanbereopened.Fromtheuserperspective,itwillbethesame procedureasforinitiatingachat(section3.2.4.1),exceptthatwhenthenewmessageis sent,thenewIMsessionwillbeestablished. Thedevicethenwilldisplaythepreviousstoredconversationswiththatcontactpreceding thecurrentactiveone. 3.2.4.11 StoreandForwardMode StoreandforwardfunctionalityisoptionalanditisuptoeachMNOtodeployit(i.e.to deployanIMServersupportingstoreandforwardbecausetheclientsideimplementation ismandatoryinanycase). In order to provide store and forward functionality, an IM Server is required. There are threepossiblescenarios: Sender and receiver are on networks with an IM Server: In this case the receiver IM ServerhastheresponsibilitytostoreIMwhicharenotdelivered.ThesenderIMServer hastheresponsibilityofstoringthedelivered/displayednotificationsincasethesender isnolongeronline OnlythesenderisonanetworkwithanIMServer:ThesendersIMServertakesallthe responsibilitytostoreIMand/ordelivered/displayednotificationsincasetheycannot be delivered. Because the sender IM Server cannot have information on when the destinationisonline,aretrymechanismwillbeemployedinstead. OnlythedestinationisonanetworkwithanIMServer:ThereceiversIMServertakes alltheresponsibilitytostore IMand/ordelivered/displayednotificationsincasethey cannotbedelivered.BecausethereceiverIMServercannothaveinformationonwhen thesenderisonline,aretrymechanismwillbeemployedinstead. Inordertobeabletodeliverstoreddelivered/displayednotificationstoasenderdevice thathasbecomeoffline,withoutdisruptingtheuserexperience,theIMServersupporting store and forward functionality shall initiate a special IM session for the purpose of deliveringthesenotification.ThisspecialIMsessionshallbeautomaticallyacceptedbythe device. It is recognized by the device thanks to the wellknown URI (standfw@sip.rcse.com)uniquelyidentifyingthestoreandforwardserviceidentityinthe PAssertedIdentityheaderfield. Note that the IM Server supporting store and forward is required to send the delivered/displayed notifications to the exact device that has previously sent the associated messages. Therefore the IM Server implementing multidevice handling shall supportGRUU(seesection2.14). OtheraspectsofthestoreandforwardfunctionalityimplementationontheIMServerare outofscopeofthisspecification.PleasenoteadditionaldiagramsareprovidedinANNEX Bforreference. Finally,pleasenotethatstoreandforwardfunctionalityonthenetworksideisoptional, thereforethereisadedicatedconfigurationsetting(IMCAPALWAYSON,seesection2.1 Table5forfurtherreference)whichisusedtoconfiguretheclienttosupportornotthis functionalityandtheimplicationsontheuserexperience. Page 80 of151
RCSeAdvancedComms: Servicesandclientspecification 3.2.4.12 Multidevicehandling Multidevicehappenswhenauserisabletohavemorethanonedevice(PCand/ormobile) connectedatthesametime. When a new 1to1 chat is initiated and a message is sent from userA to a userB with multipledevicesregisteredatthesametime,thenetworkforkstheIMsessionaccording totherulesandprocedureof[RCS2OMASIMPLEENDORS]39. EachofBsdevicesthatreceivesthesessioninvitationgeneratesaSIPMESSAGEtocarry thedeliveredIMDNasper[RFC5438].Inamultidevicescenario,ifasenderreceivesmore thanoneIMDNforasentmessage,itshalldiscardallcopiesexceptthefirstoneitreceives. TheuserBwillbeabletoanswertothechatfromanyofhisdevices,butinthemoment hesendsamessagefromoneofthem,thatdeviceBwillbecometheonlyactivedevice and all the other IM sessions for the other devices will be closed. All the following messagessenttotheuserBwillbereceivedonlyintheactivedeviceB1usingthealready establishedIMsession. Deviceswitching(asper[RCS2OMASIMPLEENDORS]39): a) IfuserBclosestheIMsessionfromtheactivedevice(eitherbyclosingthechat conversation from the chat window or due to an abnormal termination), any newmessagesentbyuserAthroughthechatwillmaketheIMserverestablish againoneIMsessionperconnecteddeviceBandsendthemessagetothemall asexplainedbefore. b) If user B changes from one device B1 to another B2 by just sending a new messagetothechatfromthenewdeviceB2.ItwillsendanewINVITEwiththe messageinthesubjectfieldasusualthatwillgotoAsdevice.WhenAsdevice detectsanewINVITEsessionfromauser(B)whichalreadyhasanestablished sessionitshallenditandacceptthenewone.Allsubsequentmessageswillbe receivedonlybydeviceB2.DeviceB2mustthenstorethereceivedmessages anddisplaythemappropriately.IfAstillhasdeliveryanddisplayedreportsfor DeviceB1,theyshouldbesentbeforeAsdevicetearsdowntheoldsession. Theconversationhistoryisimplementedatdevicelevel.Theintentionforfuturereleaseis reallocatebackthisfunctionalityonthenetwork. 3.2.4.13 Switchingto1tomanyChat AgroupchatcouldbeonlystartedfromauseronaMNOwhichhasdeployedanIMAS.It is optional for a MNO to provide the 1tomany functionality, so from the terminal perspective, if there is not a configured IM conferencefactoryURI, the terminal should notallowtheusertoaddadditionalpartiestothechatnorstartingamultichat. A 1to1 chat can be converted into a 1tomany chat by any of the two users A and B addingnewuserstoit.UsersA,BwillbegiventheoptionintheirUItoselectoneormore contactsaddedtotheconversation,onlyamongthecontactsknownbytheirdevicestobe RCSeUsers. A real time check of contacts capabilities will be performed as when initiating a chat (section3.2.4.1).AnewgroupchatcomposingwindowwillbecreatedinuserAsdevice andtheresultofthischeckwillbeshowninit. Page 81 of151
RCSeAdvancedComms: Servicesandclientspecification WhenuserAsendsthefirstmessageanewonetomanychatwillbeopenedbetweenall theselectedusers,AandBasdescribedinsection3.2.5.1. ForBuseranewgroupchatcomposingwindowwillbecreatedintheusersdevice.Itis recommendedtotheUXimplementationsnottoclosethealreadyestablishedonetoone chatwindowbutjustswitchthefocustothenewcreatedgroupchatwindows. Please note Store and Forward support for 1tomany Chat is out of the scope of this specificationand,therefore,thisfunctionalityisnotrequired. 3.2.4.14 Filetransferwithin1to1chat Duringaonetoonechat,anyoftheuserswillbeabletoinitiateafiletransferfromthe chatcomposingwindow.ThefiletransferwillbeestablishedusinganewSIPsessionand carriedinanewMSRPsessionwhichisdifferentfromtheoneusedforthechatsession. Thereceivinguserwillgetthefiletransferinvitationinsidethechatwindowandwillbe abletoacceptordeclineit. If the user accepts the file transfer, the terminal will either ask the user the location to storethefileoruseadefaultdirectory.Oncereceived,theuserwillbeabletoopenthe filefromthechatcomposingwindow. 3.2.4.15 Otherfeatures Emoticons:Selectedemoticonswillbedisplayedgraphicallybutsentandreceived as text. The list of supported icons is defined in [RCS2OMASIMPLEENDORS]39 AppendixN. Spamfilter:Userwillbeallowedtoqualifyundesiredincomingchatasspam.This will prevent subsequent messages from those originators to be shown or even notifiedtotheuser.Also,thisundesiredtrafficwillnotbeacknowledgedtohave beendelivered.
3.2.4.16 Protocolflowdiagrams Pleasenotethediagramspresentedinthissectionfocusonacombinationbetweenthe userexperienceandahighlevelviewonthesignallingandmediaexchangesassociatedto chat.Thedetailedtransactionstogetherwithstoreandforwardandmultidevicescenarios arecoveredinAnnexesBandC.

3.2.4.16.1 Generalonetoonechat
In case, user A wants to chat with user B. Consequently, user A enters in the chat composingwindowbyoneoftheentrypointspresentedinprevioussectionstothechat windowandsendsthefirstmessage. InthefollowingsequenceweareassuminguserBiscurrentlyregistered,therefore,the chatcantakeplace.ClientAandB areawareofthisbecauseanOPTIONSrequesthave beencompleted(sendandreceivecapabilitiesfromtheotherend)priortoentertothe chat(e.g.whenselectingthecontactintheaddressbook).
Page 82 of151
RCSeAdvancedComms: Servicesandclientspecification UEUser/ClientA UI Client Logic MNOIMSCore RCSAS

IM
UEUser/ClientB Client Logic UI
The user enters in the onetoone IM and sends a message
SIPINVITE
IM Server could decide whether to stay in the MSRP media path (to store message historyforexample)orlettheMSRPsessionbeestablishedendtoend.
SIPINVITE SIP180RINGING SIP200OK ACK SIP180RINGING SIP200OK
ACK
MSRP MSRPsend
MSRP
MSRP200OK
TheIMsessionisnowestablishedandwillremainactiveuntiloneof thepeersleavetheonetooneIMortheinactivitytimertriggers.The usermayleavetheIM/chatwindowinthebackground,whichmeans thesessionisstillactive(canreturnafterwards).
Figure28.Onetoonechat
Note that MSRP is not only used to send messages but notifications (is composing, displayedanddelivered).Pleasenotethatpriortoacceptance,SIPMESSAGEisalsouse for this purpose (only for displayed and delivered notifications in this case). In the previousdiagram,thenotificationswereintentionallyomittedforclarity.Pleasereferto AnnexB(sectionB.1)forthecompletesequence. Incontrasttothepreviousflow,therearecaseswherethechatoriginatingusermayhave nonupdatedinformationaboutthecapabilitiesfromtheotherend.Forexample,auser wasregisteredduringthepreviouspolling.Wehaveselectedtheuserintheaddressbook,
Page 83 of151
RCSeAdvancedComms: Servicesandclientspecification however there is some latency in getting the OPTIONS message response back quickly enoughandtheuserdecidestoenterinthechat. Although unlikely, the situation where a user (user A) enters in a chat and the other user(s)(userBinthiscase)isnotregistered(nochatpossible)mayhappen.Inthiscase, theproposedsequenceisthefollowing: UEUser/ClientA UEUser/ClientB MNOIMSCore Client Client RCSAS UI UI Logic Logic IM Theuserentersintheonetoonechatandsendsamessage. At this point, the UI has allowed enough time to get the responseforthe OPTIONSmessage(i.e.wecanwait foritdue tothemoretimeconsumingUItransitions). SIP480TEMPORARILYUNAVAILABLE or SIP404NOTFOUND If the other peer is not registered or itisnotanRCSeuser,theUIenables theusertosendanSMSinstead.
Figure29.OnetoonechatbackupmechanismtosendSMS
Pleasenotetheprevioustwodiagramsdonotcoverthestoreandforwardcases.Please refertoAnnexBfordetaileddiagramscoveringstandardchatandthestoreandforward cases.
Page 84 of151
3.2.4.16.2 StoreandForward
Duetothecomplexityofthestoreandforwardscenarios,detaileddiagramsareprovided inAnnexB.
3.2.4.16.3 Multidevice
Duetothecomplexityofthemultidevicescenario,detaileddiagramsareprovidedin AnnexC.
3.2.4.16.4 Leavingaonetoonechat
Inthiscase,userAandBareinachat,howeverAwantstoleaveitbecause,forexample, thechatconversationisfinished.TherelevantUXandflowsequenceispresentedbelow: UEUser/ClientA UEUser/ClientB MNOIMSCore Client Client RCSAS UI UI Logic Logic IM Bothusersareinaonetoonechat. User A then decide to leave by closing the IM/chat SIPBYE SIPBYE SIP200OK MSRPTERMINATION MSRPTERMINATION User A requested to leave the chat, therefore,thechatwindowisclosed and the previous window (i.e. phonebookisshown) UserBdidnotclosethechatwindow,soheremainsin the chat without a session. If he/she then write a messageandsendit,anewsessionwillbeestablished (newINVITEmessageissenttostartanewsession). SIPINVITE(userA, SDP[MSRP])
Figure30.Leavingaonetoonechatsession(chatterminated)
PleasenotethattheIMServer,especiallywhenstoreandforwardisenabledcoulddecide toleavetheBsMSRPsessionopenandstartanewsessionwithuserAwhenuserBsends Page 85 of151
RCSeAdvancedComms: Servicesandclientspecification a new message. No UI indication should be done reflecting that the underlying MSRP sessionhasbeenclosed. In the next case, user A and B are in a chat, however A has to leave because an event (incoming email, incoming call, etc.) or because it decides to put the chat task in the background.Inthiscase,thechatconversationisnotfinished,sothesessioniskeptactive inthebackground. TherelevantUXandflowsequenceispresentedbelow: UEUser/ClientA UEUser/ClientB MNOIMSCore Client Client RCSAS UI UI Logic Logic IM Bothusersareinaonetoonechat. ThenUserAreceivesanincoming UserAanswersthecallsothechatwindowisreplaced bythecallscreen. At RCSe chat level, user A is still on the chat and, consequently is able to receive message. During the call,anotificationmaybedisplayedonthenotification area(topbar)whenanewchatmessageifanewchat messageisreceived. UserBdidnotclosethechatwindow,so heremainsinthechat The call ends and the user is returned to thechat
Figure31.Leavingaonetoonechatsession(leavingchatinthebackground)
Page 86 of151
3.2.4.16.5 Onetoonechatforcedtermination
Inthiscase,userAandBareinachat,howeveruserBclientfailstokeeptheconnection to the network (e.g. client error, IP reconfiguration due to a new data bearer, lost coverage,etc.): UEUser/ClientA UEUser/ClientB MNOIMSCore Client Client RCSAS UI UI Logic Logic IM Bothusersareinaonetoonechat. Suddenly, User B becomes unavailable InactivitytimerintheIM Serveristriggedanddetects thattheotherendisnot longeravailable SIPBYE SIP200OK MSRPTERMINATION
Figure32.Onetoonechatforcedtermination
Page 87 of151
3.2.4.16.6 Exchangecapabilitiesduringa1to1chat
TheassumptionsinthiscasearethatuserAandBareinachat.Thecapabilitiesofoneof theuserschange(e.g.differentdatacarrier),however,thechatcancontinue.Eventhat chatcancontinue,theotherendhastobeinformedusingtheOPTIONSmessage. UEUser/ClientA UEUser/ClientB Client Client IMS UI UI Logic Logic Core Theclientdetectsachangeon theavailablecapabilities. SIPOPTIONS(capabilitiesB) SIP200OK(updatedcapabilities forA,ifapplicable) Iffiletransferisnotlongeravailable,theiconshouldbe displayedgreyedoutandasnonclickable
Figure33.Capabilitiesexchangeduringachatsession
Page 88 of151
3.2.5 1tomanyChat
In order to implement the 1tomany chat functionality an IM server is required, and consequently, the IM CONFERENCE FACTORY URI (see section 2.1 Table 5 for reference) configurationparametershouldbecorrectlyset. It is optional for a MNO to provide the 1tomany functionality, so from the terminal perspective, if there is not a configured IM CONFERENCE FACTORY URI, the terminal should not allow the user to add additional parties to the chat nor starting a multichat. Please note that the fact that starting a 1tomany chat is not available in this scenario does not restrict the possibility to join a multichat session. Therefore, the OEM has to implementboththeonetooneandonetomanychatexperiencesevenforuserswithout aconfiguredIMCONFERENCEFACTORYURI. Pleasenotethefollowingsectionsproposeanexperiencewhichaimedtobeemployedas areferenceforOEMimplementations. Support for store and forward in 1tomany chat is not included in this version of the specification. Finally,itshouldbetakenintoaccountthatagroupchatcouldbeonlystartedfromauser onaMNOwhichhasdeployedanIMServerAS. 3.2.5.1 Initiatingachat UserAinitiatesachatbyselectingsomeofhiscontacts(B,CuptoalimitOTA/remote configured by the MNO) from the Address Book or from the IM/chat application in his mobilephone,orintheContactListfromtheBroadbandAccessPCclient,butonlyamong thecontactsknownbyhisdevicestobeRCSeuserswithIMcapability.DeviceA(either mobileorPC)willsendaqueryfortherealtimecapabilitiesofeachcontactB,C(aquery perintendedcontact)toensuretheIMserviceisavailableforthoseusersatthattime. When user A types the first message and presses the Send button, device A will establishanIMsessionwiththeIMserverandsendthemessagethroughit.TheIMserver willestablishIMSessionswiththeotherparticipantusers. WhenauserdevicereceivesagroupchatinvitationfromtheIMserver,therecipientmay acceptorrejecttheinvitationaswouldbedoneinaonetoonecaseandsubscribetothe conferenceeventpackagetoretrievethelistandstatusoftheusersintheonetomany chat.UserAsdeviceshallsubscribetotheconferenceeventpackagealso.Theidentityof eachusershallbematchedagainstthecontactlistinthedevicetopresentauserfriendly name. TheIMserverwillbeopenedA,B,Cuptoaconfiguredlimit. Inthesidesofthereceiversanotification(UI dependant)willbedisplayedondeviceto informabouttheincomingmessage.Notificationmustclearlystatethatitisamultichat, sotheusersaremadeaware Unlike [RCS2OMASIMPLEENDORS]39 once a 1tomany chat is established, any participantisallowedtoaddmorecontacts,whilethegenerallimitisnotreached.
Page 89 of151
RCSeAdvancedComms: Servicesandclientspecification 3.2.5.2 GeneralBehaviour Thesamebehaviourfromonetoonechatappliesto1tomanychatexceptof: 3.2.5.3 Closingmultichat AnyoftheparticipantscanclosehisIMsessionassociatedwithanestablishedmultichat. ThiscanbedonefromthechatcomposingwindoworintheIM/chatapplication. WhenuserCcloseshisIMsessionitwillbenotifiedtotheotherusersinthechatthrough a predefined indication C has left the conversation, and their devices will remove him from the displayed recipients. A new Conversation is created in user Cs device history withthemessagesassociatedtothechatuptothepointheleft. AchatisclosedwhenthelessthantheminimumnumberofRCSusersdefinedforagroup chat remain in the group chat all RCS users close their IM sessions, or when a chat inactivitytimeoutexpires. 3.2.5.4 Protocolflowdiagrams
3.2.5.4.1 StartamultipleIMsessionfromtheIMcompositionwindow
Displayingandlocalstorageofanactiveconversation, Leavingthechatcomposingwindow(seesection3.2.4.5) Deliveryanddisplaynotifications(seesections3.2.2.3and3.2.2.4respectively)are notrequired Storeandforwardmode(seesection3.2.4.11)isnotrequired Delivery and display notifications, as covered in sections 3.2.2.3 and 3.2.2.4 respectively,arenotrequired.
Inthiscase,userAandBareinachat,anduserAdecidestoaddathirduser(userC)to thechatsession.TherelevantUXandflowsequenceispresentedbelow:
Page 90 of151
User/ClientA UI Client Logic IMSCore

IM
User/ClientB Client Logic UI
MSRPsessionestablished
User A decides to add new participants to a 1to1 establishedIMsession.
User is displayed the list of RCSe users and chooses one or more contacts. No real time capabilitycheckisdone(i.e.noOPTIONS)
SIPINVITE SIP200OK ACK
Sets RequestURI to the CONFERENCE FACTORYURIfortheIMserviceinthe HomeNetworkoftheIMUser. AddalltheinviteduserinaMIMEresourcelist bodyincludingalsotheidentityof theoriginalinviteduserwithSessionReplaces)
SIPINVITE(withSessionReplaces)
SIP200OK
User/ClientC
ACK
SIPINVITE SIPBYE(oftheoriginalsession) SIP200OK SIP200OK
ACK ConferencesessionestablishedbetweenABandC
Figure34.Multichatsessioninitiation
Page 91 of151
3.2.5.4.2 GetparticipantsofmultichatIMsession
Thefollowingflowiscomplementarytotheprevioususecaseasitpresentsindetailshow togetinformationonthechatparticipants.Pleasenotetheseexchangeswereomittedin thepreviousdiagram: User/ClientA User/ClientB Client Client IMS UI UI Logic Logic Core ConferencesessionestablishedbetweenABandothers Once joined a one to many IM session the client shall subscribe the conference event togettheconferenceparticipant. SIPSUBSCRIBE(conferencepackageevents) SIP200OK SIPNOTIFY(withlistofparticipants) SIP200OK Client updates the participant list and displaystheconnectionstateforeachone.
Figure35.Multichatsessioninitiation(II):Getparticipants
Page 92 of151
3.2.5.4.3 StartagroupchatsessionfromaIM/chatapplication
User/ClientA UI Client Logic IMS Core
User/ClientC Client Logic UI
The user enters the IM/chat application and chooses to start a new chat
User is displayed the list of RCSe users and choosesmorethanonecontact.Norealtime capabilitycheckisdone(i.e.noOPTIONS)
SIPINVITE SIP200OK
Sets RequestURI to the CONFERENCE FACTORYURIfortheIMserviceinthe HomeNetworkoftheIMUser. AddalltheinvitedusersinaMIMEresource list body using the copyControl attribute set to"to"only
ACK SIPINVITE SIP200OK ACK Conferencesessionestablished betweenABandC
Figure36.StartagroupchatfromtheIM/chatapplication
Page 93 of151
3.2.5.4.4 AddaparticipanttoanalreadyestablishedonetomanyIMsession
ConferencesessionestablishedbetweenAandBandothers
User decides to add one ore more new contactstotheconference. TheuserisdisplayedalistofRCSeusers.
Userselectoneormorecontacts.
SIPREFER SIP200OK ACK
SIPNOTIFY(withlistofparticipants)
SIP200OK
SIPNOTIFY(withlistofparticipants) SIP200OK
Clientupdatestheparticipantlist withthejoinedparticipants
Client updates the participant list with the joinedparticipants
Figure37.Addingnewuserstoamultichatsession
Page 94 of151
3.2.5.4.5 SendingaIMmessagefromtheIMmultiplesessionwindow
ConferencesessionestablishedbetweenABandC
Usertypesamessageand pressSendbutton Messageispresented on the other participant display indicatingitiscoming fromuserA
MSRPSEND MSRP200OK
MSRPSEND MSRP200OK MSRPSEND MSRP200OK
Figure38.Chatmessagesequenceonamultichatsession
Page 95 of151
3.2.5.4.6 UserinamultipleIMsessiongoesoffline
Inthefollowingflow,usersAandBareinachatamongothers(multichat);suddenlyUser Bgoesoffline(e.g.losestheconnectiontothenetwork): MNOIMSCore User/ClientA User/ClientB Client Client RCSAS UI UI Logic Logic IM ConferencesessionestablishedbetweenABandothers User B goes offline due to lost of coverageorungracefulshutdown IMS core detects user going offline and updatesparticipantlistsendingtheeventtoall theconferenceparticipant SIPNOTIFY(withlistof participantsstatus) SIP200OK Clientupdatestheparticipantlistanddisplays theconnectionstateforeachone. The user going offline is faded out (or similar)andremovedfromparticipantlist.
Figure39.Forcedchatterminationinamultichatsession
Page 96 of151
3.2.5.4.7 LeavingaIMmultiplesession
This case is equivalent to the previous one however in this case, User B leaves the chat intentionally: User/ClientA User/ClientB Client Client IMS UI UI Logic Logic Core ConferencesessionestablishedbetweenABandothers User B closes the IM composition window. SIPBYE SIP200OK SIPNOTIFY (withlistofparticipantsstatus) SIP200OK Clientupdatestheparticipantlistanddisplays theconnectionstateforeachone. The user going offline is faded out (or similar)andremovedfromparticipantlist.
Figure40.Leavingamultichatsession
Page 97 of151
3.3 RCS-e services during a call

Among the different RCSe services, during a call the user will be able to access the following: Share a video (video share, identical behaviour and version as defined in RCS Release2specifications):Thevideocanbeoriginatedfrom: o Thefrontcamera(me) o Therearcamera(whatIsee) o Afile(videostreaming) Share a picture (image share identical behaviour and version as defined in RCS Release2specifications):Thepicturecanbe: o Apicturetakenusingthefrontcamera(me) o Apicturetakenusingtherearcamera(whatIsee) o Afile(sendstoredimage) Theusershouldbeabletoknowwhetheroneorbothservicesareavailableduringthecall, therefore,bothendsneedtobeupdatedoftherespectivecapabilitiesoftheotherendto avoidshowingaserviceasavailablewhenitisnolongerthecase. Both video and image share are unidirectional however it is possible to establish simultaneous image and/or video share sessions in each direction. For example when referringtobidirectionalvideoshare,wemeanthatonceuserAissharingvideowithuser Bandprovidetherightcoverageconditionsareinplace,userBcouldalsostarttoshare video with A simultaneously. In this case each video share session is independent and shouldbehandledseparately.Thesameexamplewouldalsoapplytoimageshareorto thecombinationofvideoandimageshare,eachserviceinonedirection. For video share, the preferred media transport is RTP. For image share, MSRP is the preferredmediatransport.
In the following sections we will be showing the relevant message flows and reference userexperience(UX).Pleasenotethatthefollowingassumptionshavebeenmade: For simplicity, the internal mobile network interactions are omitted in the diagramsshowedinthefollowingsections. Theterminalsupports2GDTMmode,therefore,itisalwayspossibletogracefully terminatethetransactionprovidetheterminalremainson.Incase2GDTMisnot supported,theusecaseofoneoftheendsgoingto2Gwouldbeequivalenttothe clienterrorone. Theterminalcomeswithafrontandrearcamera.Ifoneorbothmissing,theuser shouldbenotifiedonlywiththeavailableoptions. Priortothecall,theuseraccesseditsaddressbook,calllogordialpadtomakethe call.Asdescribedbefore,whiletheseactionsareperformedanOPTIONSmessage issenttodoublechecktheavailablecapabilities.Inthefollowingdiagramsweare assumingthatthisexchange(OPTIONSandresponse)havealreadytakeplace,and therefore,bothendsareawareofthecapabilitiesand,consequently,theavailable Page 98 of151
RCSeAdvancedComms: Servicesandclientspecification RCSeservices.Ifthatisnotthecase,theOPTIONSmessageshouldbesendatthe sametimethecallisbeingsetup. In the diagrams we have assumed for simplicity that MSRP chunking is enabled. ThisisjustforrepresentationpurposesanditisuptotheOEMtomakeadecision onwhetherMSRPchunkingisenabledornot.
Page 99 of151
3.3.2 Exchangecapabilitiesduringacall
TheassumptionsinthiscasearethatuserAandBareinacall.Thecapabilitiesofoneof theuserschange(e.g.differentdatacarrier),therefore,theotherendhastobeinformed usingtheOPTIONSmessage. UEUser/ClientA UEUser/ClientB Client Client IMS UI UI Logic Logic Core
Theclientdetectsachangeon theavailablecapabilities. SIPOPTIONS(updatedcapabilities forB,ifapplicable) SIP200OK(updatedcapabilities forA,ifapplicable) Available services are updated (greying out relevant icons) basedonreceivedcapabilities. Figure41.Capabilitiesexchangeduringacall
Page 100 of151
3.3.3 Sharevideoduringacall
The assumptions in this case are that both user A (wanting to share video) and user B (recipient wanting to receive it), have successfully exchanged the OPTIONS message, therefore,bothclientsareawarethatvideosharingispossible(bothUEsona3G+orWi Fi). InthiscaseRTPistheprotocolusedtostreamthevideodata,soitcanbereproducedin realtimeontheotherend. UEUser/ClientA UEUser/ClientB Client Client IMS UI UI Logic Logic Core Theuserselectstosharevideo usingtherelevanticon/button The user can choose to share from the front/back camera or stream a file. In this case we are assuming that in all the three cases,RTPisusedfortransport. Therefore,whenstreamingafile,thedatais extracted from the file and, potentially, transcodeddependingonthefileencoding SIPINVITE(SDPvideosession) IfchoosingMediagallery,theuserwillbe presented with the videos available in the media library, allowing him/her to choose onetoshare.Oncethisisdone,theuserwill bebacktothecallscreen. SIP200OK(SDPvideosession) RTP(videodata) RTP(videodata) RTP(videodata) RTP(videodata) RTP(videodata) RTP(videodata) RTP(videodata)
Figure42.Sharevideoduringacall
Page 101 of151
3.3.4 Stopsharingvideo(RTP)duringacall:Senderinitiated
TheassumptionsinthiscasearethatuserAissharingvideo(RTP)withuserB,however userAdoesnotlongerwanttokeepsharingit. UEUser/ClientA UI Client Logic IMS Core UEUser/ClientB Client Logic UI
RTP(videodata) RTP(videodata) RTP(videodata) RTP(videodata) RTP(videodata) RTP(videodata) RTP(videodata)

Theuserpressstopsharing
SIPBYE SIP200OK(byeACK)
As it is streaming and the received cannot verify EOF,anOPTIONSisissuedtounderstandifitisa user initiated termination (video is available) or not(videocapabilitystatusneedtobeupdated
SIPOPTIONS(updaterequest,capabilitiesB) SIP200OK(updatedcapabilities forAI,ifapplicable)
Available RCSe services are updated (greying out relevant icons)basedonreceivedcapabilities.
Figure43.Senderstopssharingvideoduringacall
Page 102 of151
3.3.5 Stopsharingvideo(RTP)duringacall:Receiverinitiated
Thiscaseisequivalenttothepreviousone,howeveritisthereceiver(userB)whodoes notlongerwanttokeepreceivingit. UEUser/ClientA UEUser/ClientB Client Client IMS UI UI Logic Core Logic
RTP(videodata) RTP(videodata) RTP(videodata) RTP(videodata) RTP(videodata) RTP(videodata) RTP(videodata)

Theuserpressstopreceiving
SIPBYE SIP200
As it is streaming and the received cannot verify EOF,anOPTIONSisissuedtounderstandifitisa user initiated termination (video is available) or not(videocapabilitystatusneedtobeupdated
SIPOPTIONS(updaterequest,capabilitiesA) SIP200OK(updatedcapabilities forBI,ifapplicable)
Available Services are updated (greying out relevant icons) based on receivedcapabilities.
Figure44.Receiverwantsnolongertoreceivevideoduringacall
Page 103 of151
3.3.6 Stopsharingvideo(RTP)duringacallbecausetherequiredcapabilityisno longeravailable

TheassumptionsinthiscasearethatuserAissharingvideo(RTP)withuserB,andeither AorBarenolongercapable(e.g.theterminalisbusy,no3G+orWiFicoverageavailable suddenlyhoweveritdoesnottriggeranIPreconfigurationorlossofconnection)tosend orreceivevideo.Pleasenoteintheexample,weassumedthesender(userA)istheone losingthecapability.Thissequencewillbeequivalentfor: Sender (user A) loses the capability to receive video: The BYE and OPTIONS exchangewouldbeinitiatedbythesender(userA)inthiscase. Bothlosethecapabilitytosharevideo:TheBYEandOPTIONSexchangemessage wouldbeinitiatedbythefirstonetolosethecapabilityinthiscase. By losing the capability to send video, we are excluding the case there is an IP reconfiguration. Please note that particular case is covered under the Client Error sectionlaterinthischapter UEUser/ClientA UEUser/ClientB Client Client IMS UI UI Logic Logic Core RTP(videodata) RTP(videodata) RTP(videodata) RTP(videodata) RTP(videodata) RTP(videodata) RTP(videodata) Loses the ability tostreamvideo SIPBYE SIP200OK(byeACK) SIP200OK(updatedcapabilities forA,ifapplicable) SIPOPTIONS(updaterequest,capabilitiesB) sharevideoiconisgreyedout(notavailable). share pic icon will be also greyed out or not dependingoncapabilities
Figure45.Videocannolongerbesharedduringacall(capabilitynotavailable)
Page 104 of151
3.3.7 Sharepicturesduringacall
TheassumptionsinthiscasearethatbothuserA(wantingto sharepicture)anduserB (recipient wanting to receive it), have successfully exchanged the OPTIONS message, therefore,bothclientsareawarethatfilesharingispossible(bothUEsona3G+orWiFi). UEUser/ClientA UEUser/ClientB Client IMS Client UI UI Logic Logic Core The user selects to share a picture using the relevant Theusercanchoosetosharefromthefront/backcamera orstreamafile.Inthecameracases,theuserwillbe offeredtotakeapicture. IfchoosingMediagallery,theuserwillbepresented withthepicturesavailableinthemedialibrary,allowing him/hertochooseonetoshare. Oncethisisdone,theuserwillbebacktothecallscreen. SIPINVITE(SDPMSRPsession) SIP200OK(SDPMSRPsession) MSRPSEND(imagedata) MSRP200OK MSRPSEND(imagedata) MSRP200OK MSRPSEND(imagedata) MSRP200OK Filetransfer Filetransfer completed(size completed(size check) check) SIPBYE SIP200 Onceitistransferfinished,thepictureisshowninbothends. UserAcanchoosetohidethesharedpicture(backtofirstscreen) UserBcanchoosetoshowthedefaultimagehe/shehasforuserA inthephonebook(ifany,otherwiseadummy).
Figure46.Sharingapictureduringacall
Page 105 of151
3.3.8 Stopsharingapictureduringacall:Senderinitiated
TheassumptionsinthiscasearethatuserAissharingapicturewithuserB,thetransferis stillongoing,howeveruserAdoesnotlongerwanttokeepsharingit. User/ClientA UI Client Logic IMS Core User/ClientB Client Logic UI
MSRPSEND(imagedata) MSRP200OK MSRPSEND(imagedata) MSRP200OK MSRPSEND(imagedata) MSRP200OK

Theuserpressstopsharing
SIPBYE SIP200OK
Filetransfernot completed(sizecheck)
SIPOPTIONS(updaterequest,capabilitiesB) SIP200OK(updatedcapabilities forAI,ifapplicable)
Available RCSe services are updated (greying out relevant icons)basedonreceivedcapabilities.
Figure47.Senderstopssharingapictureduringacall
Page 106 of151
3.3.9 Stopsharingapictureduringacall:Receiverinitiated
Thiscaseisequivalenttothepreviousone,howeveritisthereceiver(userB)whodoes notlongerwanttokeepreceivingit. User/ClientA User/ClientB Client IMS Client UI UI Logic Core Logic
MSRPSEND(imagedata) MSRP200OK MSRPSEND(imagedata) MSRP200OK MSRPSEND(imagedata) MSRP200OK

Theuserpresscancelstransfer
SIPBYE
SIP200OK
Filetransfernot completed(sizecheck)
SIPOPTIONS(updaterequest,capabilitiesA) SIP200OK(updatedcapabilities forBI,ifapplicable)
Available RCSe services are updated (greying out relevant icons) basedonreceivedcapabilities.

Figure48.Receiverstopspicturesharing
Page 107 of151
3.3.10 Stopsharingapictureduringacallbecausetherequiredcapabilityisno longeravailable

TheassumptionsinthiscasearethatuserAissharingapicturewithuserB,thetransfer hasnotyetfinished,andeitherAorBarenolongercapable(e.g.theterminalisbusy)to keep sharing/receiving . Please note in the example, we assumed the sender (user A) is theonelosingthecapability,however,thesequencewillbeequivalentfor: Receiver (user B) loses the capability to receive video: The BYE and OPTIONS exchangewouldbeinitiatedbythereceived(userB)inthiscase. Bothlosethecapabilitytosharevideo:TheBYEandOPTIONSexchangewouldbe initiatedbythefirstonetolosethecapabilityinthiscase. Pleasenotethereisanexceptiontostopafiletransferduetocapabilities.Ifoneofthe users is left with 2G coverage (DTM terminal) once a transfer has started and the handover did not trigger an IP bearer reconfiguration, the transfer may continue until completed.Oncethetransferiscompleted,picturesharingwillnotbelongeravailableas aserviceduringthecall.
Page 108 of151
RCSeAdvancedComms: Servicesandclientspecification UI ClientA Client Logic IMS Core ClientA Client Logic UI
MSRPSEND(Imagedata) MSRP200OK MSRPSEND(Imagedata) MSRP200OK MSRPSEND(Imagedata) MSRP200OK

The client loses the ability tosendpicturefile
SIPBYE SIP200OK(byeACK) SIPOPTIONS(updaterequest,capabilitiesB) SIP200OK(updatedcapabilities forAI,ifapplicable)
On both sides, the share video and share pic icons aregreyedout(notavailable).
Figure49.Apicturecannolongerbesharedduringacall(capabilitynotavailable)
Page 109 of151
3.3.11 Declinesharevideoorpictureduringacall
UserAwantstoshareavideoorpicturewithuserB,howeverhe/shedoesnotwantto receiveit.Pleasenoteweareassumingthatbothvideoandimageshareispossible(right capabilities). UEUser/ClientA UEUser/ClientB UI Client Logic
Theuserselectstosharevideo ora pictureusingtherelevant
IMS Core
Client Logic
UI
The user chooses where to share video or a picture from.
SIPINVITE(SDPvideoor filesharingsession)
Theuserselectsnot toaccept
SIP 603 ERROR

Figure50.Userdeclinessharingapictureduringacall
Page 110 of151
3.3.12 Nongracefultermination(sender):Videoorpicturesharing
User A is sharing video or a picture with user B. Suddenly, user A connection to the network fails (e.g. due to a client error, because the phone reboots, no data bearer, a switchindatacarrier[e.g.3G+to3G]causesanIPlayerreconfiguration,etc.). Inthefollowingflow,weareassumingavideotransfer(RTP)wastakingplacebutitwillbe equivalent to the case an MSRP (image or video sharing via file) was taking place (not finished): User/ClientA User/ClientB Client Client IMS UI UI Core Logic Logic RTP(videodata) RTP(videodata) RTP(videodata) RTP(videodata) RTP(videodata) RTP(videodata) RTP(videodata) Client error, it is not possibletosharevideo Original phonebook pictures are shown(firstscreen) No services are shown until status isclarified Timerexpires SIPBYE SIPOPTIONS(updaterequest,capabilitiesB) Depending on the scenario, the sender SIP200orSIPxxxERROR(BYEresponse) may respond the BYE/OPTIONS.Ifnotthe networkwouldsendthe SIP200OK(updatedcapabilitiesfor AI,ifapplicable)orSIP404/480 associatederror Available RCSe services are updated (greying out relevanticons)basedonreceivedcapabilities.Ifnot received,noserviceswillbeavailable
Figure51.Nongracefultermination(sender)forvideo
Page 111 of151
3.3.13 Nongracefultermination(receiver):Videoorpicturesharing
In order to protect the Core SIP network from cases where both the sender and the receiver become unresponsive or unreachable before any of them had the time to terminate the SIP session, the RCSe Client shall use the procedure described in [RFC4028]45inasimilarwaytotheonemandatedin[RCS2OMASIMPLEENDORS]39;i.e. theRCSeclientinitiatingaSIPsessionmustrequesttheroleofrefresherandtheoption tag'timer'mustbeincludedinaSupportedheader. TheSessionExpiresandMinSEvaluesannouncedbyanRCSeclientmustbeconfigurable bytheMNO. This use case is identical to the previous one, except that in this case User B (receiver) loses the ability to receive/process MSRP (e.g. due to a client error, because the phone reboots,nodatabearer,etc.). InthefirstflowdiagramwehaveassumedanimageMSRPtransactionwastakingplace:
TheSessionTimersintheSessionInitiationProtocol(SIP)IETFRFCisavailableat http://tools.ietf.org/html/rfc4028.
45
Page 112 of151
MSRPSEND(Imagedata) MSRP200OK MSRPSEND(Imagedata) MSRP200OK MSRPSEND(Imagedata)
Originalphonebookpictures areshown(firstscreen) No RCSe services are shown until status is clarified
It is not able to receive/processMSRP
Timerexpires
SIPBYE SIPOPTIONS(updaterequest,capabilitiesA)
Depending on the scenario, the sender may respond the BYEmessage
SIP200orSIPxxxERROR SIP200OK(updatedcapabilitiesforBI, ifapplicable)orSIP404/480

Available RCSe services are updated (greying out relevanticons)basedonreceivedcapabilities.Ifnot received,noRCSeserviceswillbeavailable
Figure52.Nongracefulterminationofvideoorpicturesharingduringacall
Page 113 of151
RCSeAdvancedComms: Servicesandclientspecification InthesecondflowwehaveassumedavideoRTPtransactionwastakingplace: User/ClientA User/ClientB Client IMS Client UI UI Logic Logic Core RTP(videodata) RTCPRR RTP(videodata) RTP(videodata) RTCPRR RTCPRR Client error, it is not possibletoreceivevideo RTP(videodata) RTP(videodata) RTP(videodata) RTP(videodata) Timerexpires without receivingRTCP Originalphonebookpictures RTCPRR areshown(firstscreen) No RCSe services are shown until status is clarified SIPBYE SIPOPTIONS(updaterequest,capabilitiesA) Depending on the scenario, the receiver may respond the SIP200OK(BYEACK) BYEmessage SIP200OK(updatedcapabilities forBI,ifapplicable) Available RCSe services are updated (greying out relevant icons) based on received capabilities. If not received,noRCSeserviceswillbeavailable
Figure53.Nongracefulterminationofvideosharingduringacall
Page 114 of151
3.3.14 Multipartycallandimage/videoshare
Once a CS call is established between two users, it is possible for any of them to add another party to the call, and consequently, initiate a multiparty call. From RCS services pointofviewandaspresentedinsection2.7,theimageandvideoshareservicesarenot availableduringamultipartycall,therefore,theterminalneedstomanagethefollowing scenarios: TheuserswereinaCScallwithoutusingtheimageorvideoshareservices:Inthis case,switchingtoamultipartycallmeansthattheendstartingtheprocesshasto send an SIP OPTIONS message with a capability update (as described in section 3.3.2) indicating that image and video share services are no longer available (i.e. onscreenicons/layoutupdatedaccordingly). TheuserswereinaCScallusingvideoshare:Inthiscase,switchingtoamultiparty call means ending the video share service, either sender or receiver terminated upon circumstances as described in sections 3.3.4 and 3.3.5 respectively. In both cases, a capabilities exchange using SIP OPTIONS takes place and, consequently, the end initiating the multiparty call should report the image and video share services/capabilities are no longer available (i.e. onscreen icons/layout updated accordingly). TheuserswereinaCScallusingimageshare(transfernotcompleted):Inthiscase, switchingtoamultipartycallmeansendingtheimageshareservice,eithersender orreceiverterminateduponcircumstancesasdescribedinsections3.3.8and3.3.9 respectively.Inbothcases,acapabilitiesexchangeusingSIPOPTIONStakesplace and, consequently, the end initiating the multiparty call should report the image and video share services/capabilities are no longer available (i.e. onscreen icons/layoutupdatedaccordingly). TheuserswereinaCScallusingimageshare(completed):Inthiscase,switchingto amultipartycallmeansthepictureisnolongershowninthecallscreenandthat theendstartingtheprocesshastosendanSIPOPTIONSmessagewithacapability update (as described in section 3.3.2) indicating that image and video share servicesarenolongeravailable(i.e.onscreenicons/layoutupdatedaccordingly). Itshouldbealsonotedthatfromthemomenttheusersenterinamultipartycall,itisnot necessarytoperformthecapabilityexchangedescribedinsection3.3.2. Finally,ifthemultipartyisagainconvertedintoastandardcall(i.e.againa1to1call),this eventshouldbetreatedasanewcallestablishmentmeaningthatacapabilityexchange viaOPTIONSneedstotakeplaceand,consequently,therelevantonscreeniconsneedto beupdated.
Page 115 of151
3.3.15 Callonholdandimage/videoshare
OnceaCScallisestablishedbetweentwousers,itispossibleforanyofthemtoputthe otherpartyonhold.FromRCSservicespointofviewandaspresentedinsection2.7,the image and video share services are not available during a call which is not active, therefore,theterminalneedstomanagethefollowingscenarios: TheuserswereinaCScallwithoutusingtheimageorvideoshareservices:Inthis case,puttingthecallonholdmeansthattheendstartingtheprocesshastosend an SIP OPTIONS message with a capability update (as described in section 3.3.2) indicating that image and video share services are no longer available (i.e. on screenicons/layoutupdatedaccordingly). TheuserswereinaCScallusingvideoshare:Inthiscase,puttingthecallonhold meansendingthevideoshareservice,eithersenderorreceiverterminatedupon circumstancesasdescribedinsections3.3.4and3.3.5respectively.Inbothcases,a capabilities exchange using SIP OPTIONS takes place and, consequently, the end initiating the multiparty call should report the image and video share services/capabilities are no longer available (i.e. onscreen icons/layout updated accordingly). TheuserswereinaCScallusingimageshare(transfernotcompleted):Inthiscase, putting the call on hold putting the call on hold switching to a multiparty call meansendingtheimageshareservice,eithersenderorreceiverterminatedupon circumstancesasdescribedinsections3.3.8and3.3.9respectively.Inbothcases,a capabilities exchange using SIP OPTIONS takes place and, consequently, the end initiating the multiparty call should report the image and video share services/capabilities are no longer available (i.e. onscreen icons/layout updated accordingly). TheuserswereinaCScallusingimageshare(completed):Inthiscase,puttingthe callonholdswitchingtoamultipartycallmeansthepictureisnolongershownin thecallscreenandthattheendstartingtheprocesshastosendanSIPOPTIONS message with a capability update (as described in section 3.3.2) indicating that imageandvideoshareservicesarenolongeravailable(i.e.onscreenicons/layout updatedaccordingly). Itshouldbealsonotedthatfromthemomentthecallisputonhold(i.e.callnoactive): It is not necessary to perform the capability exchange described in section 3.3.2, and, If there is another active call, the behaviour regarding to image and video share (capability exchange and the services itself) should not be affected by the fact anothercallisonhold. Finally, if the call is again made active, this event should be treated as a new call establishmentmeaningthatacapabilityexchangeviaOPTIONSneedstotakeplaceand, consequently,therelevantonscreeniconsneedtobeupdated. Page 116 of151
3.3.16 Waitingcallandimage/videoshare
Awaitingcallisanonactivecalltherefore,consequentlywiththeinformationpresented in section 2.7, it should not be possible to access the image and video share services betweenthecallerandreceiver. Pleasenotehavingawaitingcallwillnotaffectthebehaviourforimageandvideoshare (capabilityexchangeandtheservicesitself)ontheactivecall.
3.3.17 Callsfromprivatenumbers
Whenacallisreceivedandthecallercannotbeidentified(e.g.hiddennumber),itshould alsonotbepossibletoaccesstheimageandvideoshareservicesbetweenthecallerand receiver.
Page 117 of151
3.4 File transfer

Thefiletransfer(FT)serviceenablestheuserstosharefilesbetweenoneormoreusers instantaneously. As mentioned before, this service comes with some requirements (bandwidth, free space on the receivers device); therefore, even if a RCSe contact is registered,itmaynotbepossibletosharefiles. FromtheUXexperiencepointofview,therearefivepossibleentrypointstothisservice: Addressbook/Calllog:Filesharecanbeinitiatedwithanyregisteredcontact providingtherightcapabilitiesareinplacecontactorientedinitiation.Following theaddressbookinteraction,thelistofavailablefilesisdisplayed,sotheusercan selectoneormoretoshare.Oncefiletransfercommences,theprogresscanbe checkedinthestandardnotificationarea.
Figure54.ReferenceUXforaccessingfilesharefromaddressbook/calllog
Media gallery/File browser: The user can browse, select a file (or multiple files) and then share with one or more RCSe users task contact oriented initiation. OnlyRCSecapableusersshallbedisplayedascandidaterecipientofthefile.

Figure55.ReferenceUXforaccessingfilesharefrommediagalleryorfilebrowser
In the previous figure, once file transfer is selected, the user will be presented with the complete list of RCSe contacts (including contacts which are currently notregistered). Inthiscase,anOPTIONSmessageissentonceacontactisselectedfromthelist. Page 118 of151
RCSeAdvancedComms: Servicesandclientspecification Cameraapplication:Theexperienceisanalogoustothemediagallery/filebrowser experiencewiththedifferencethattheuserisabletoonlyselectthelastpicture orvideo(and,insomecases,onepictureorvideofromthecameragallery)tobe shared. IM/chatwindow:FromtheIM(onetooneIMonly)windowafilecanbeshared using the relevant button/icon. The experience is identical to the address book/calllog. The user is redirected to the media gallery or file explorer where he/shecanchooseafilewhichthenshared.

Figure56.ReferenceUXforaccessingfilesharefromaIMwindow
Call screen (image share): We can share a picture either by using the camera (frontorback)orchoosingafilefromthemediagallery.Pleasenotethishasbeen coveredindetailinsection3.3. Whentransferringafilewhilstnotinanexistingsession(i.e.whennotinacallorIM)and after the transfer has commenced (i.e. the user accepted the incoming file) the file transferispresentedtotherecipientinaIMUX.Thisestablishesacommunicationcontext for the transfer as the recipient may want to know why the sender is sharing the file. Please note that at the time the file is presented, the IM session is not started; the IM sessionwillonlystartifandwhenthereceiversendsaIMmessagebacktothesender.
Figure57.ReferenceUXforfiletransferonthereceiverside
Page 119 of151
Intheproceedingsectionswewillbeshowingtherelevantmessageflowsandreference userexperience(UX).Thesearebaseduponthefollowingassumptions: For simplicity, the internal mobile network interactions are omitted in the diagramsshowedinthefollowingsections. Itisassumedthatbythetimethefiletransferbegins,bothsenderandrecipient haveexchangedtheircapabilitiesusingtheOPTIONSmessage.Pleasenotethatif thereisaUIflowwhichinvalidatesthisassumption,OPTIONSmessagesshouldbe exchangedbetweenthesenderandthereceiver(bidirectional). AllthefiletransferserviceexchangespresentedinthisdocumentfollowtheRCS GSMAspecificationforfiletransfer46.Inotherwords,RCSemakesuseofRCSFile Transferservicefunctionalitywithoutanymodificationsoradditions.
3.4.2 Selectingthefiletransferrecipient(s)
Thefirststepforauserwillingtoshareafilefromthemediagalleryorfilebrowseristo select the file and then choose the user or group of users the file will be shared with. PleasenotethatthelistwhichispresentedtotheusercontainsRCSecontactswhichmay ormaynotberegistered.Inadditiontothis,thecapabilitiestheclienthasforacontact maynothavebeenupdated. Therefore,thefirststepistodeterminewhetherthefilecanbesharedwiththeselected user(i.e.shouldberegisteredandtherightcapabilitiesshouldbeinplace)
By this reference we include both technical and functional references contained in the RCS Release 2 specifications(TechnicalRealizationv2.0[RCS2TECREAL],ServiceDefinitionv2.0[RCS2SD]andFunctional Descriptionv2.0[RCS2FUNDESC]availableatwww.gsmworld.com)
46
Page 120 of151
RCSeAdvancedComms: Servicesandclientspecification UEUser/ClientA UI Client Logic IMS Core UEUser/ClientB Client Logic UI
UserAgoestothemediagalleryandselectsafileto share.
Only the RCSe services contacts (from the list the client must maintain and that includes Registered and unregistered contacts) are displayed. User A can choose oneormorecontactstoshareafile Onceacontactisselected,theclientwillsendanoptionmessagetogetthe lateststatus(i.e.ifthefiletransferispossiblebasedoncapabilities).Please notethatiftheOPTIONmessageexchangeisfastenough,theUItransition willhidethedelay(i.e.thisscreenwouldnotbeshown)
SIPOPTIONS(capabilitiesA, SDPsupportedformat) SIP200OK(capabilitiesB,SDP supportedformats)
Following the algorithm, the other client sends an options message to update the capabilitiesfromtherequester.
Once a contact is selected and the OPTION message exchangeconfirmsthatthenecessarycapabilitiesarein place,userAcanselectContinueandproceedwiththe filetransfer
Figure58.Selectinguserswhensharingafilefromthemediagallery/filebrowser
Page 121 of151
3.4.3 Standardfileshareprocedure
IndependentlyofthefileshareUXentrypoint,oncethefilesandusersareselected,the transfer can start. Please note that if a user chooses to share several files with one or moreusers,eachindividualfiletransfer(1fileto1useronly)areserialised(i.e.itisnot supportedtohavesimultaneousfilesharingprocessesrunninginparallel). Inthefollowingdiagram,itisassumedthereceiveracceptsthetransfer. UEUser/ClientA UEUser/ClientB Client Client IMS UI UI Logic Logic Core Thefiletransfergoestothebackground,however it can be tracked in the notification area. Please note that if started from a chat window, the transferinformationispresentedonscreen. SIPINVITE(SDPMSRPsession) SIP200OK(SDPMSRPsession) ACK MSRP SEND(filedata) MSRP200OK MSRPSEND(filedata) MSRP200OK Filetransfer Filetransfer completed(sizecheck) completed(sizecheck) SIPBYE SIP200OK
Figure59.StandardfiletransfersequencediagramSuccessfultransfer
Page 122 of151
RCSeAdvancedComms: Servicesandclientspecification Inthefollowingdiagram,UserBrejectsthetransfer. UEUser/ClientA UEUser/ClientB Client IMS Client UI UI Logic Logic Core Thefiletransfergoestothebackground,however it can be tracked in the notification area. Please note that if started from a chat window, the transferinformationispresentedonscreen. Theuserselectsnot toaccept SIPINVITE(SDPMSRPsession) SIP 603 ERROR User A receives a notification
Figure60.StandardfiletransfersequencediagramReceiverrejectsthetransfer
3.4.4 Fileshareerrorcases
There are several scenarios in which a file transfer can result in an error. All these scenarioshavebeenalreadycoveredinprevioussections: Either the sender or the receiver decides to cancel the operation before the transfer is completed. The relevant sequences are equivalent to the diagrams presentedforfilesharingduringavoicecallinsections3.3.8and3.3.9 Eitherthesenderorthereceiverlosestheconnectiontothenetwork,beforethe transfer is completed. The relevant sequences are equivalent to those presented forfilesharingduringavoicecallinsections3.3.12and3.3.13 Finally,pleasenotethatifduringafiletransferthecapabilitiesofoneoftheendschanges, thefiletransfermaybeaffected: If the receiver runs out of space, the sequence should be equivalent to that presentedinsection3.3.10. Ifoneoftheendshandoversinto2G(2GGPRSdatacoverage)withoutlosingtheIP configuration,thefiletransfershouldcontinueuntilfinished.
Page 123 of151
3.4.5 Fileshareandfiletypes
Inprinciple,theRCSefiletransferservicecomeswithoutalimitationonthefilesizesor types, meaning any kind of file can be transferred using this service. Taking this into accountthisandwiththeaimofprovidingallthenecessaryfactstothereceivertomake aninformeddecisiononwhethertoacceptorrejectthefile,auserreceivingafiletransfer invitationshouldbeinformedatleastof: a) The size of the file: This is mainly to protect the user from unexpected charges and/orlongtransfers. b) Thefiletype:Inthiscaseandtomakeitmoreintuitive,thehandsetshouldpresent totheuserwhetherthefilewhichisbeingtransferredcanbehandled/displayed bythedevice. For example, if a user receives an invitation to receive a PDF document and his/her handsetcannotprocessthatsortofdocuments,aninformativemessagewiththesizeand thefactthatthefiletypeisnotsupportedshouldbepresentedtotheuserpriortothe decisionofacceptingorrejectingthefiletransfer. Finally note that each individual MNO may introduce restrictions taking into account differentconsideration(e.g.security,intellectualproperty,etc.).
3.4.6 Filesizeconsiderations
Inordertopreventboththeabuseofthefiletransferfunctionalityandprotectcustomers from unexpected charges, a configurable size limitation (refer to FT WARN SIZE and FT MAXSIZEinTable5forreference)maybeenabled. Fromtheuserexperiencepointofviewandassumingthesizelimitationisinplace(i.e.the valuesaredifferentfrom0): If a file transfer (send or receive) involves a file bigger than FT WARN SIZE, the terminal should warn the user of the potential associated charges and get confirmationfromtheusertogoahead. If the file is bigger than FT MAX SIZE, a warning message will be displayed when tryingtosendorreceiveafilelargerthatthementionedlimitandthetransferwill becancelled(i.e.atprotocollevel,theSIPINVITEwillneverbesentorarejection responsewillbesenttotheotherenddependingonthecase).
Page 124 of151
A. ANNEX A: Extensions to the data model

Aspresentedinsection1andin section2.1Table5,thisspecificationproposesa setof extensions to the RCS data model part of the GSMA RCS Release 2 specification and describedindetailin[RCS2MO]47. The aim of this section is to provide the necessary data to complement the mentioned GSMARCSRelease2specificationdocumentationand,consequently,provideacomplete configurationdatamodelbothforMNOsandOEMsreference.
A.1 Management objects parameter additions

Pleasenotetheinformationcontainedinthissectionisaimedtocomplementsection2of [RCS2MO]47.
A.1.1 Presencerelatedconfiguration
RCSe specification includes the following additional presence related configuration parameters: Configuration parameter Description RCSeusage
USEPRESENCE
This parameter allows enabling or disabling the presencerelatedfeaturesonthedevice.Ifsetto Mandatory 0, presence is disabled, if set to 1, presence is parameter enabled and the parameters pertaining to presencedefinedin[RCS2_MO]47apply.
Table22.RCSeadditionalpresencerelatedconfigurationparameters
A.1.2 XDMrelatedconfiguration
RCSe specification does not include any additional XDM related parameters apart from thosementionedin[RCS2MO]47.Nevertheless,itshouldbenotedthatalltheparameters becomeoptionalastheyareonlyneededwhenemployingpresencerelatedfunctionality likepresencediscoveryorprofileinformationsharing.
A.1.3 IMrelatedconfiguration
RCSespecificationincludesthefollowingadditionalIMrelatedconfigurationparameters:
47
RichCommunicationSuiteRelease2ManagementObjectsVersion2.014February2011availableat www.gsmworld.com
Page 125 of151
RCSeAdvancedComms: Servicesandclientspecification Configuration parameter Description RCSeusage
ThisistheparametercontainingtheURI fortheIMserver.Theparameteris optionalandifnotconfigured,means IMCONFERENCE thattheMNOisnotdeployinganIM FACTORYURI server.Consequentlyfeaturesrequiring IMserver(i.e.1tomanyIM)willnotbe availableforthosecustomers. This parameter configures the client to support store and forward when presentingtheIMcapabilitystatusforall thecontacts.Ifsetto1,theIMcapability for all RCSe contacts will be always IMCAPALWAYSON reported as available. Otherwise (0), the capability will be reported based on the algorithmpresentedinsection2.7. Forexample,thiscanbeusedinMNOs thatareimplementingthestoreand forwardfunctionalityforIM In case, IM CAP ALWAYS ON is set to enabled (use of store and forward), a new parameter is used called IM WARN SFforUIpurposeonly. If IM WARN SF parameter is set to (1) then,whenchattingwithcontactswhich are offline (Store and Forward), the UI must warn the user of the circumstance (e.g.messageonthescreen). Otherwise (0), there wont be any difference at UX level between chatting with an online or offline (Store and Forward)user.
Optional Parameter
Optionalparameter
(ItismandatoryifIM CONFERENCEFACTORYURIis set)
Optional parameter
(ItismandatoryifIM CONFERENCEFACTORYURIis setandIMCAPALWAYSONis setto1)
IMWARNSF
Table23.RCSeadditionalIMrelatedconfigurationparameters
ItshouldbealsonotedthattheIMCONFERENCEFACTORYURIparametershouldbe configuredusingtheconffctyuriparameterasdescribedinsection4.4of[RCS2MO]47. Again,ifsetto0,thislimitationdoesnotapply.
Page 126 of151
A.1.4 Filetransferrelatedconfiguration
RCSe specification includes the following additional file transfer related configuration parameters: Configurationparameter FTMAXSIZE Description ThisisafiletransfersizelimitinKB.Ifa file is bigger than FT MAX SIZE, the transferwillbeautomaticallycancelled. Pleasenotethatifsetto0,thislimitwill notapply. This is a file transfer size limit in KB to warn the user that a file may end up in significantcharges. Pleasenotethatifsetto0,theuserwill notbewarned. RCSeusage Mandatory Parameter Mandatory Parameter
FTWARNSIZE
Table24.RCSeadditionalfiletransferrelatedconfigurationparameters
It should be also noted that the FT MAX SIZE parameter should be configured using the MaxSizeFileTrparameterasdescribedinsection4.4of[RCS2MO]47.Again,ifsetto0,this limitationdoesnotapply.
A.1.5 IMSCore/SIPrelatedconfiguration
RCSe specification includes nospecific additional IMS Core/SIP related configuration parameters.Nevertheless,itshouldbenotedthat: The USER and PASSWD parameters described in section 2.1 Table 5 map to the UserNameandUserPwdparametersdescribedin[RCS2MO]47. TheTELURIandSIPURIparametersmaptothePublic_user_identityparameters definedin[3GPPTS24.167]48andendorsedin[RCS2MO]47. The SIP PROXY parameter maps to the parameters hosted by the LBO_P CSCF_Address subtree defined in [3GPP TS 24.167]48 and endorsed in the Managed Object document (version 1.1) part of the GSMA RCS Release 2 specification. When the PCSCF address has an "FQDN" type, the SIP transport protocolcanbeselectedbytheRCSeclientthankstoDNSSRVrequests.Whenthe PCSCF address has an "IP Address" type, the SIP transport protocol should be selectedbasedonMNOcustomizedsettings.
A.1.6 ConfigurationrelatedwithAddressbookBackup/Restore
RCSespecificationdoesnotincludeanyadditionaladdressbookbackup/restorerelated configurationparameters.
A.1.7 Configurationrelatedwithsecondarydeviceintroduction
3GPPTS24.1673rdGenerationPartnershipProject;TechnicalSpecificationGroupCoreNetworkand Terminals;3GPPIMSManagementObject(MO)
48
Page 127 of151
RCSeAdvancedComms: Servicesandclientspecification RCSespecificationdoesnotincludeanyadditionalsecondarydeviceintroductionrelated configurationparameters.
A.1.8 Capabilitydiscoveryrelatedconfiguration
Although not covered in RCS Release 2, RCSe specification includes the following additionalcapabilitydiscoveryconfigurationparameters: Configuration parameter Description RCSeusage
This is frequency in seconds to run a periodic capabilities update for all the contacts in the phone address book whose capabilities are not POLLINGPERIOD Mandatory available (e.g. nonRCSe users) or are expired parameter (seeCAPABILITYINFOEXPIRYparameter. Pleasenotethatifsetto0,thisperiodicupdate isnolongerperformed. When using the OPTIONS discovery mechanism and with the aim of minimizing the traffic, an Optional expiry time is set in the capability information CAPABILITYINFO parameter fetched using options. When performing a (Itismandatoryif EXPIRY whole addressbook capability discovery (i.e. POLLINGPERIODis settoavalue polling), an OPTIONS exchange takes place only greaterthan0) ifthetimesincethelastcapabilityupdatetook placeisgreaterthanthisexpirationparameter Thisparameterallowsenablingordisablingthe usageofcapabilitiesdiscoveryviapresence.If Optional setto0,theusageofdiscoveryviapresenceis parameter disabled.Ifsetto1,theusageofdiscoveryvia (Itismandatory PRESENCEDISCOVERY andbecomes presenceisenabled.Thisparameterwill relevantonlyif consequentlyinfluencetheinclusionofthe USEPRESENCEis setto1) associatedtagtopresencediscoveryinOPTIONS exchanges. Thisparameterallowsenablingordisablingthe usageofthesocial information via presence.If Optional setto0,theusageofthesocial information via parameter presencefeatureisdisabled.Ifsetto1,the (Itismandatory PRESENCEPROFILE social information via presencefeatureis andbecomes relevantonlyif enabled.Thisparameterwillconsequently USEPRESENCEis influencetheinclusionoftheassociatedtagto setto1) social information via presenceinOPTIONS exchanges.
Table25.RCSeadditionalcapabilitydiscoveryrelatedconfigurationparameters
Page 128 of151
A.1.9 APNconfiguration
Although not covered in RCS Release 2, RCSe specification includes the following additional configuration parameters targeting APN configuration (see sections 2.10 and 2.11): Configuration parameter RCSEONLYAPN Description This is the reference/identifier to the APN configuration which should be used to provide PS connectivity ONLY to RCSe as describedinsection2.10. Asdescribedinsection2.10,theusershallbe able configure to allow or disallow RCSe and/or internet traffic in the handset settings. If this parameter is set to 1, the setting is shown permanently. Otherwise it may be (MNOdecision)onlyshownduringroaming.
Table26.RCSeroamingconfigurationparameters
RCSeusage Mandatory Parameter
ENABLERCSE SWITCH
Mandatory Parameter
A.1.10 Enduserconfirmationparameters
Although not covered in RCS Release 2, RCSe specification includes the following additional configuration parameters targeting the End user confirmation configuration (seesection2.13): Configuration parameter ENDUSERCONFREQ ID
Description Thisisidentityusedforsendingtheenduser confirmationrequest.

Table27.RCSeenduserconfirmationparameters
RCSeusage Optional Parameter
A.2 RCS Management trees additions

Pleasenotetheinformationcontainedinthissectionisaimedtocomplementsection4of [RCS2MO]47. Please note that a common change to all the configuration sub trees describedinthissectionisthatthetypepropertyfortherootnodes(i.e./<X>nodesroot) isurn:gsma:mo:rcs:rcseinsteadurn:gsma:mo:rcs:2.0.
A.2.1 IMSsubtreeadditions
TheRCSespecificationdoesnotincludeanyadditionstotheRCSIMSsubtreedefinedin [RCSMO]47. Page 129 of151
RCSeAdvancedComms: Servicesandclientspecification As the RCS Release 2 specification does not cover OMACP configuration of RCS clients, theassociatedOMACPconfigurationXMLstructurefortheparametersdefinedintheRCS Release2specificationispresentedinthetablebelow: <characteristic type=IMS> <characteristic type=LBO_P-CSCF_Address> <parm name=Address value=X/> <parm name=AddressType value=X/> </characteristic> <parm name=NatUrlFmt value=X/> <parm name=IntUrlFmt value=X/> <parm name=Q-Value value=X/> <characteristic type=ServCapPresentity> <parm name=VoiceCall value=X/> <parm name=Chat value=X/> <parm name=SendSms value=X/> <parm name=FileTranfer value=X/> <parm name= VideoShare value=X/> <parm name=ImageShare value=X/> </characteristic> <parm name=MaxSizeImageShare value=X/> <parm name=MaxSizeImageShare value=X/> </characteristic>
<characteristic type=APPAUTH> <parm name=AuthType value=X/> Table28.IMSsubtreeassociatedOMACPconfigurationXMLstructure49
A.2.2 Presencesubtreeadditions
RCSespecificationincludesthefollowingadditionstothepresencesubtree: PresenceMO Ext <X> usePresence presencePrfl
Figure61.RCSeadditionstothepresenceMOsubtree
The associated OMACP configuration XML structure is presented in the table below. Please note that as RCS R2 specification does not cover OMACP configuration of RCS clients,bothRCS(markedinblue)andRCSeparametersareshowninthiscase(notonly additionsasforOMADM):
Please note the values marked in red refer to the objects described in [3GPPTS24.167]aspresentedin sectionA.1.5.
49
Page 130 of151
<characteristic type=PRESENCE> <parm name=usePresence value=X/> <parm name=presencePrfl value=X/> <parm name=AvailabilityAuth value=X/> <characteristic type=FAVLINK> <parm name= AutMa value=X/> <characteristic type=LINKS> <parm name= OpFavUrl1 value=X/> <parm name= OpFavUrl2 value=X/> <parm name= OpFavUrl3 value=X/> </characteristic> </characteristic> <parm name=IconMaxSize value=X/> <parm name=NoteMaxSize value=X/> <characteristic type=SERVCAPWATCH> <parm name=FetchAuth value=X/> <parm name= ContactCapPresAut value=X/> </characteristic> <characteristic type=ServCapPresentity> <parm name=WATCHERFETCHAUTH value=X/> </characteristic> <parm name=client-obj-datalimit value=X/> <parm name=content-serveruri value=X/> <parm name=source-throttlepublish value=X/> <parm name=max-number-ofsubscriptions-inpresence-list value=X/> <parm name=service-uritemplate value=X/> </characteristic> Table29.PresencesubtreeassociatedOMACPconfigurationXMLstructure
Node:/<X> UnderthisinteriornodeareplacedtheRCSparametersrelatedtoPresence Status Occurrence Format Min.AccessTypes Required One node Get
Table30.PresenceMOsubtreeadditionpresencenode
Values:N/A TypepropertyoftheNodeis:urn:gsma:mo:rcs:rcse:presenceext AssociatedOMACPcharacteristictype:PRESENCE
Node:/<X>/usePresence Leafnodethatdescribeswhetherthepresencerelatedfeaturesareenabledordisabled onthedevice.
Page 131 of151
RCSeAdvancedComms: Servicesandclientspecification Status Required Occurrence One Format Bool Min.AccessTypes Get/Put
Table31.PresenceMOsubtreeadditionparameters(usePresence)
Node:/<X>/presencePrfl Leafnodethatdescribeswhetherthesocialpresencefunctionalityissupported. Status Occurrence Format Min.AccessTypes Required One Bool Get/Put
Values: 1, the presence related features are enabled. 0, the presence related featuresaredisabled. Postreconfiguration actions: The client should be reset and should perform the completefirsttimeregistrationprocedurefollowingareconfiguration(e.g.OMA DM/OMACP)asdescribedinsection2.2.2.1. AssociatedOMACPparameterID:usePresence
Table32.CapabilityMOsubtreeadditionparameters(presencePrfl)
Values:Ifsetto1,itissupported.Ifsetto0,itisnotsupported. Postreconfiguration actions: The client should be reset and should perform the complete firsttime registration procedure following a reconfiguration (e.g. OMA DM/OMACP)asdescribedinsection2.2.2.1. AssociatedOMACPparameter:presencePrfl
A.2.3 XDMSsubtreeadditions
TheRCSespecificationdoesnotincludeanyadditionstotheRCSXDMSsubtreedefined in[RCSMO]47. As the RCS R2 specification does not cover OMACP configuration of RCS clients, the associatedOMACPconfigurationXMLstructurefortheparametersdefinedintheRCSR2 specificationispresentedinthetablebelow: <characteristic type=XDMS> <parm name=RevokeTimer value=X/> <parm name=XCAPRootURI value=X/> <parm name=XCAPAuthenticationUserName value=X/>
<parm name=XCAPAuthenticationSecret value=X/> <parm name=XCAPAuthenticationType value=X/> </characteristic> Table33.XDMSsubtreeassociatedOMACPconfigurationXMLstructure
Page 132 of151
A.2.4 IMMOsubtreeaddition
RCSespecificationincludesthefollowingadditionstotheIMMOsubtree: IMMO Ext imCapAlwaysON <X> imWarnSF ftWarnSize
Figure62.RCSeadditionstotheIMMOsubtree
The associated OMACP configuration XML structure is presented in the table below. Please note that as RCS R2 specification does not cover OMACP configuration of RCS clients,bothRCS(markedinblue)andRCSeparametersareshowninthiscase(notonly additionsasforOMADM): <characteristic type=IM> <parm name= imCapAlwaysON value=X/> <parm name= imWarnSF value=X/> <parm name= ftWarnSize value=X/> <parm name=ChatAuth value=X/> <parm name=SmsFallBackAuth value=X/> <parm name=AutAccept value=X/> <parm name=MaxSize1to1 value=X/> <parm name=MaxSize1toM value=X/> <parm name=TimerIdle value=X/> <parm name=MaxSizeFileTr value=X/>
<parm name=pres-srv-cap value=X/> <parm name=max_adhoc_group_size value=X/> <parm name=conf-fcty-uri value=X/> <parm name=exploder-uri value=X/> </characteristic> Table34.IMsubtreeassociatedOMACPconfigurationXMLstructure
Node:/<X> UnderthisinteriornodeareplacedtheRCSparametersrelatedtotheIMconfiguration. Status Occurrence Format Min.AccessTypes Required One node Get
Table35.IMMOsubtreeadditionIMnode
Values:N/A TypepropertyoftheNodeis:urn:gsma:mo:rcs:rcse:imext AssociatedOMACPcharacteristictype:IM Node:/<X>/imConfFacURI Page 133 of151
RCSeAdvancedComms: Servicesandclientspecification LeafnodethatprovidestheIMserverconferencefactoryURI.Ifnotpresent,itmeansthe MNOisprovidingtheIMservicewithoutanIMserver. Status Occurrence Format Min.AccessTypes Optional One chr Get/Put
Table36.IMMOsubtreeadditionparameters(imConfFacURI)
Values:IMserverconferencefactoryURI Postreconfiguration actions: As the client remains unregistered during configuration,therearenoadditionalactionsapartfromderegisteringusingthe old(section2.2.2.4)andregisteringback(section2.2.2.2)usingthenewparameter. AssociatedOMACPparameter:imConfFacURI
Node:/<X>/imCapAlwaysON Leaf node that describes whether the IM capability needs to be on independently on whethertheotherendisregistered.ForexamplethiscanbeusedinMNOsprovidingthe storeandforwardfunctionalityforIM Status Occurrence Format Min.AccessTypes Optional One bool Get/Put
Table37.IMMOsubtreeadditionparameters(imCapAlwaysOn)
Node:/<X>/imWarnSF LeafnodethatdescribeswhethertheUXshouldalerttheuserthatmessagesaredifferent whenstoreandforwardisavailable. Status Occurrence Format Min.AccessTypes Optional One bool Get/Put
Values:1,RCSIM/chatserverstoreandforwardisenabled;0,isdisabled Postreconfiguration actions: As the client remains unregistered during configuration,therearenoadditionalactionsapartfromderegisteringusingthe oldconfiguration(section2.2.2.4)andregisteringback(section2.2.2.2)usingthe newparameter. AssociatedOMACPparameter:imCapAlwaysOn
Table38.IMMOsubtreeadditionparameters(imWarnSF)
Values:1,theuserisawareviaUXonwhenthemessagesaredifferedusingS&F.0, theuserisnotawareonwhenmessagesarediffered. Postreconfiguration actions: As the client remains unregistered during configuration,therearenoadditionalactionsapartfromderegisteringusingthe Page 134 of151
RCSeAdvancedComms: Servicesandclientspecification oldconfiguration(section2.2.2.4)andregisteringback(section2.2.2.2)usingthe newparameter. AssociatedOMACPparameter:imWarnSF
Node:/<X>/ftWarnSize Leafnodethatdescribesthefiletransfersizethreshold(inKB)onwhentheusershouldbe warnedaboutthepotentialchargesassociatedtothetransferofalargefile. Status Occurrence Format Min.AccessTypes Required One Int Get/Put
Table39.IMMOsubtreeadditionparameters(ftWarnSize)
Values:Thefilesizethreshold(inKB)or0todisablethewarning Postreconfiguration actions: As the client remains unregistered during configuration,therearenoadditionalactionsapartfromderegisteringusingthe oldconfiguration(section2.2.2.4)andregisteringback(section2.2.2.2)usingthe newparameter. AssociatedOMACPparameter:ftWarnSize
A.2.5 CapabilitydiscoveryMOsubtree
RCSespecificationincludesthefollowingadditions ofa newconfigurationsubtree,the capabilitydiscoveryMOsubtree.PleasenotethissubtreeisnotincludedinRCSRelease2 specification,sonoothernodesfrompreviousspecificationsneedtobeadded: CapDiscoveryMO Ext pollingPeriod <X> capInfoExpiry presenceDisc
Figure63.RCSeadditions,capabilitysubtree
TheassociatedOMACPconfigurationXMLstructureispresentedinthetablebelow: <characteristic type=CAPDISCOVERY> <parm name=pollingPeriod value=X/> <parm name=capInfoExpiry value=X/> <parm name=presenceDisc value=X/> </characteristic>
Table40.CapabilitysubtreeassociatedOMACPconfigurationXMLstructure
Node:/<X> UnderthisinteriornodeareplacedtheRCSparametersrelatedtocapabilitydiscovery. Page 135 of151
RCSeAdvancedComms: Servicesandclientspecification Status Required Occurrence One Format node Min.AccessTypes Get
Table41.CapabilityMOsubtreeadditioncapabilitydiscoverynode
Values:N/A TypepropertyoftheNodeis:urn:gsma:mo:rcs:rcse:icapdisext AssociatedOMACPcharacteristictype:CAPDISCOVERY
Node:/<X>/pollingPeriod Leafnodethatdescribesthetimerinsecondsbetweenqueryingallthecontactsinthe addressbooktoupdatethecapabilities. Status Occurrence Format Min.AccessTypes Required One Int Get/Put
Table42.CapabilityMOsubtreeadditionparameters(pollingPeriod)
Node:/<X>/capInfoExpiry Leafnodethatdescribesthevalidityofthecapabilityinformationstoredintheterminalin seconds Status Occurrence Format Min.AccessTypes Optional One Int Get/Put
Values:Thetimeinseconds.Ifsetto0,theperiodiccapabilityupdate(polling)is notperformed Postreconfiguration actions: As the client remains unregistered during configuration,therearenoadditionalactionsapartfromderegisteringusingthe oldconfiguration(section2.2.2.4)andregisteringback(section2.2.2.2)usingthe newparameter. AssociatedOMACPparameter:pollingPeriod
Table43.CapabilityMOsubtreeadditionparameters(capInfoExpiry)
Values:Thetimeinseconds. Postreconfiguration actions: As the client remains unregistered during configuration,therearenoadditionalactionsapartfromderegisteringusingthe oldconfiguration(section2.2.2.4)andregisteringback(section2.2.2.2)usingthe newparameter. AssociatedOMACPparameter:capInfoExpiry
Page 136 of151
RCSeAdvancedComms: Servicesandclientspecification Node:/<X>/presenceDisc Leafnodethatdescribeswhetherthecapabilitydiscoveryusingpresenceissupported. Status Occurrence Format Min.AccessTypes Required One Bool Get/Put
Table44.CapabilityMOsubtreeadditionparameters(presenceDisc)
Values:Ifsetto1,itissupported.Ifsetto0,itisnotsupported. Postreconfiguration actions: The client should be reset and should perform the complete firsttime registration procedure following a reconfiguration (e.g. OMA DM/OMACP)asdescribedinsection2.2.2.1. AssociatedOMACPparameter:presenceDisc
A.2.6 APNconfigurationMOsubtree
RCSespecificationincludesthefollowingadditions ofa newconfigurationsubtree,the roaming MO sub tree. Please note this sub tree is not included in RCS Release 2 specification,sonoothernodesfrompreviousspecificationsneedtobeadded: APNMO Ext <X> rcseOnlyAPN enableRcseSwitch
Figure64.RCSeadditions,roamingsubtree
TheassociatedOMACPconfigurationXMLstructureispresentedinthetablebelow: <characteristic type=APN> <parm name=rcseOnlyAPN value=X/> <parm name=enableRcseSwitch value=X/> </characteristic>
Table45.APNsubtreeassociatedOMACPconfigurationXMLstructure
Node:/<X> UnderthisinteriornodeareplacedtheRCSparametersrelatedtoroaming. Status Occurrence Format Min.AccessTypes Required One node Get
Table46.APNMOsubtreeadditioncapabilitydiscoverynode
Values:N/A Page 137 of151
RCSeAdvancedComms: Servicesandclientspecification TypepropertyoftheNodeis:urn:gsma:mo:rcs:rcse:apnext AssociatedOMACPcharacteristictype:APN
Node:/<X>/rcseOnlyAPN LeafnodethatdescribestheAPNtobeusedastheRCSeroamingAPNasdescribedin section2.10. Status Occurrence Format Min.AccessTypes Required One chr Get/Put
Table47.RoamingMOsubtreeadditionparameters(rcseOnlyAPN)
Node:/<X>/enableRcseSwitch LeafnodethatdescribeswhethertoshowtheRCSeenabled/disabledswitchpermanently asdescribedinsection2.10. Status Occurrence Format Min.AccessTypes Required One chr Get/Put
Values:TheAPNnameortheidentifierusedonthephonefortheRCSeonlyAPN Postreconfiguration actions: As the client remains unregistered during configuration,therearenoadditionalactionsapartfromderegisteringusingthe oldconfiguration(section2.2.2.4)andregisteringback(section2.2.2.2)usingthe newparameter. AssociatedOMACPparameter:rcseOnlyAPN
Table48.RoamingMOsubtreeadditionparameters(enableRcseSwitch)
Values: If set 1, the setting is shown permanently. Otherwise it may (MNO decision)beonlyshownduringroaming. Postreconfiguration actions: As the client remains unregistered during configuration,therearenoadditionalactionsapartfromderegisteringusingthe oldconfiguration(section2.2.2.4)andregisteringback(section2.2.2.2)usingthe newparameter. AssociatedOMACPparameter:enableRcseSwitch
A.2.7 OtherRCSeconfigurationsubtree
RCSe specification includes the following additions of a new configuration sub tree, containingtheremainingRCSeconfigurationparameters.Pleasenotethissubtreeisnot included in RCS Release 2 specification, so no other nodes from previous specifications needtobeadded:
Page 138 of151
OtherMO
Ext <X> endUserConfReqId

Figure65.RCSeadditions,othersubtree
TheassociatedOMACPconfigurationXMLstructureispresentedinthetablebelow: <characteristic type=OTHER> <parm name=endUserConfReqId value=X/> </characteristic>

Table49.OthersubtreeassociatedOMACPconfigurationXMLstructure
Node:/<X> UnderthisinteriornodeareplacedtheRCSparametersrelatedtoroaming. Status Occurrence Format Min.AccessTypes Required One node Get
Table50.OtherMOsubtreeadditioncapabilitydiscoverynode
Values:N/A TypepropertyoftheNodeis:urn:gsma:mo:rcs:rcse:otherext AssociatedOMACPcharacteristictype:OTHER
Node:/<X>/endUserConfReqId Leaf node that describes the identity (passertedid) used for sending the end user confirmationrequestasdescribedinsection2.13. Status Occurrence Format Min.AccessTypes Required One chr Get/Put
Table51.OtherMOsubtreeadditionparameters(endUserConfReqId)
Values: The identity (passertedid) used for sending the end user confirmation request Postreconfiguration actions: As the client remains unregistered during configuration,therearenoadditionalactionsapartfromderegisteringusingthe oldconfiguration(section2.2.2.4)andregisteringback(section2.2.2.2)usingthe newparameter. AssociatedOMACPparameter:endUserConfReqId
Page 139 of151
A.3 OMA-CP specific configuration and behaviour

A.3.1 OMACPconfigurationXMLstructure
Inadditiontotheparametersandcharacteristicstypecorrespondencespresentedinthe previous section, it is necessary to define the following mandatory configuration XML elements: The XML shall contain an APPLICATION characteristic type, this APPLICATION characteristicshallatleastcontainthefollowingparameters: o APPID:ShallbesettoRCSe The SIP authentication configuration shall be included under an APPAUTH characteristic type (consistently with the structure presented in section A.1.5 Table28).
<?xml version="1.0"?> <wap-provisioningdoc version="1.1"> <characteristic type="APPLICATION"> <parm name="APPID" value="RCS-e"/> </characteristic> <characteristic type=IMS> </characteristic> <characteristic type=APPAUTH> <parm name=AuthType value=X/> <parm name=Realm value=X/> <parm name=UserName value=X/> <parm name=UserPwd value=X/> </characteristic> <characteristic type=PRESENCE> </characteristic> <characteristic type=XDMS> </characteristic> <characteristic type=CAPDISCOVERY> </characteristic> <characteristic type=APN> </characteristic> <characteristic type=OTHER> </characteristic> </wap-provisioningdoc> Table52.RCSeOMACPconfigurationXMLstructure Table53.CompleteRCSeOMACPconfigurationXMLstructure
Page 140 of151
B. ANNEX B: IM Store and forward diagrams

B.1 IM without store and forward
User A
Send msg1 SIP INVITE (subject=msg1) CPIM (imdn.messageID=1) SIP 183 SESSION PROGRESS 180 RINGING SIP MESSAGE (no subject) CPIM (imdn.messageID=1, delivered) SIP INVITE (subject=msg2) CPIM (imdn.messageID=2) Send msg2 180 RINGING SIP MESSAGE (no subject) CPIM (imdn.messageID=2, delivered) Msg2 delivered 603 DECLINE (previous invite) ACK SIP 200 OK ACK MSRP SESSION established MSRP SEND (notification) CPIM (imdn.messageID=1, displayed) MSRP SEND CPIM (imdn.messageID=2, displayed) MSRP SEND (msg3) CPIM (imdn.messageID=3) MSRP 200 OK Msg3 delivered Msg3 read MSRP SEND CPIM (imdn.messageID=3, delivered) MSRP SEND CPIM (imdn.messageID=3, displayed)
IM-AS
SIP INVITE (subject=msg1) CPIM (imdn.messageID=1) SIP 183 SESSION PROGRESS 180 RINGING SIP MESSAGE (no subject) CPIM (imdn.messageID=1, delivered) SIP INVITE (subject=msg2) CPIM (imdn.messageID=2) 180 RINGING SIP MESSAGE (no subject) CPIM (imdn.messageID=2, delivered) 603 DECLINE (previous invite) ACK SIP 200 OK ACK MSRP SESSION established MSRP SEND (notification) CPIM (imdn.messageID=1, displayed)
IM-AS
SIP INVITE (subject=msg1) CPIM (imdn.messageID=1) 180 RINGING SIP MESSAGE (no subject) CPIM (imdn.messageID=1, SIP INVITE (subject=msg2) CPIM (imdn.messageID=2) 180 RINGING SIP MESSAGE (no subject) CPIM (imdn.messageID=2, delivered) 603 DECLINE (previous invite) ACK SIP 200 OK ACK MSRP SESSION established MSRP SEND (notification) CPIM (imdn.messageID=1, displayed)
User B
Msg1 shown in pop-up
Msg1 delivered
User opens chat window
Msg1 read Msg2 read Send msg3
MSRP SEND (msg3) STORE&FORDWARD: USER B OFFLINE CPIM (imdn.messageID=3) MSRP 200 OK MSRP SEND CPIM (imdn.messageID=3, delivered) MSRP SEND CPIM (imdn.messageID=3, displayed) MSRP 200 OK MSRP SEND CPIM (imdn.messageID=3, delivered) MSRP SEND CPIM (imdn.messageID=3, displayed)
MSRP SEND CPIM (imdn.messageID=2, displayed) Figure 66. Standard chat without MSRP SEND (msg3) CPIM (imdn.messageID=3)
store and
MSRP SEND CPIM (imdn.messageID=2, displayed) forward
Assumption: The chat window remains open so messages are read as they are delivered
Figure67.IMflowwithoutstoreandforward * *:CheckNOTE1insectionB.7
Page 141 of151
B.2 Store and forward: Receiver offline

User A
SIP INVITE (subject=msg1) CPIM (imdn.messageID=1) SIP 183 SESSION PROGRESS SIP 200 OK ACK MSRP SESSION established MSRP SEND (msg2) CPIM (imdn.messageID=2) MSRP 200 OK MSRP SEND (msg3) CPIM (imdn.messageID=3) MSRP 200 OK
IM-AS
IM-AS
User B
Send msg1
SIP INVITE (subject=msg1) CPIM (imdn.messageID=1) SIP 183 SESSION PROGRESS SIP 200 OK ACK MSRP SESSION established MSRP SEND (msg2) CPIM (imdn.messageID=2) MSRP 200 OK MSRP SEND (msg3) CPIM (imdn.messageID=3) MSRP 200 OK
SIP INVITE (subject=msg1) CPIM (imdn.messageID=1) User offline 480 TEMPORARILY UNAVAILABLE
Messages stored: Msg1 Msg2 Msg3 ID1 ID2 ID3
Figure68.Storeandforward:Receiveroffline* *:CheckNOTE1insectionB.7
Page 142 of151
B.3 Store and forward: Message deferred delivery with sender still on an active IM session
User A IM-AS
Messages stored: Msg1 Msg2 Msg3 ID1 ID2 ID3
IM-AS
User B is back online SIP INVITE (subject=msg1) CPIM (imdn.messageID=1) 180 RINGING
User B
MSRP sessions were previously established
Msg1 delivered
MSRP SEND CPIM (imdn.messageID=1, delivered)
SIP MESSAGE (no subject) CPIM (imdn.messageID=1, delivered) SIP INVITE (subject=msg2) CPIM (imdn.messageID=2) 180 RINGING Msg2 shown in pop-up
Msg2 delivered
SIP MESSAGE (no subject) CPIM (imdn.messageID=2, delivered) 603 DECLINE (previous invite) SIP 200 OK ACK MSRP SESSION established User opens chat window
Msg1 read
Msg2 read
MSRP SEND CPIM (imdn.messageID=1, displayed) MSRP SEND CPIM (imdn.messageID=2, displayed)
MSRP SEND CPIM (imdn.messageID=1, displayed) MSRP SEND CPIM (imdn.messageID=2, displayed) MSRP SEND (msg3) CPIM (imdn.messageID=3) MSRP 200 OK MSRP REPORT CPIM (imdn.messageID=3) MSRP SEND CPIM (imdn.messageID=3, delivered) MSRP SEND CPIM (imdn.messageID=3, displayed) SIP BYE SIP 200 OK
Assumption: The chat window remains open so messages are read
Msg3 delivered
MSRP SEND CPIM (imdn.messageID=3, delivered) MSRP SEND CPIM (imdn.messageID=3, displayed)
Msg3 read
Figure69.Storeandforward:Message(s)differeddeliverywithasenderstillonanMSRPsession* *:CheckNOTES1,2and3insectionB.7
The session is closed when all stored messages are delivered, if the user writes a reply a new session is established
Page 143 of151
B.4 Store and forward: Message deferred delivery with sender online

User A
IM-AS
Messages stored: Msg1 ID1 Msg2 ID2 Msg3 ID3
IM-AS
User B
User B is back online SIP INVITE (User B, p-Asserted-ID=rcse-standfw@<domain> a=sendonly) SIP 200 OK MSRP SESSION established SEND ONLY Msg1 delivered MSRP SEND CPIM (imdn.messageID=1, delivered) MSRP SEND CPIM (imdn.messageID=2, delivered) SIP INVITE (User B, p-Asserted-ID=rcse-standfw@<domain> a=sendonly) SIP 200 OK MSRP SESSION established SEND ONLY MSRP SEND CPIM (imdn.messageID=1, delivered) MSRP SEND CPIM (imdn.messageID=2, delivered)
SIP INVITE (subject=msg1) CPIM (imdn.messageID=1) 180 RINGING SIP MESSAGE (no subject) CPIM (imdn.messageID=1) SIP INVITE (subject=msg2) CPIM (imdn.messageID=2) 180 RINGING SIP MESSAGE (no subject) CPIM (imdn.messageID=2) 603 DECLINE (previous invite) SIP 200 OK
Auto-accepts based on pAsserted-ID
Msg2 delivered MSRP SEND CPIM (imdn.messageID=1, displayed) MSRP SEND CPIM (imdn.messageID=2, displayed) MSRP SEND CPIM (imdn.messageID=1, displayed) MSRP SEND CPIM (imdn.messageID=2, displayed)
Msg1 read
ACK MSRP SESSION established MSRP SEND CPIM (imdn.messageID=1, displayed) MSRP SEND CPIM (imdn.messageID=2, displayed) MSRP SEND (msg3) CPIM (imdn.messageID=3) MSRP 200 OK MSRP SEND CPIM (imdn.messageID=3) MSRP SEND CPIM (imdn.messageID=3, delivered) MSRP SEND CPIM (imdn.messageID=3, displayed) SIP BYE SIP 200 OK
Msg2 read
Msg3 delivered
MSRP SEND CPIM (imdn.messageID=3, delivered) MSRP SEND CPIM (imdn.messageID=3, displayed) SIP BYE SIP 200 OK
Msg3 read
SIP BYE SIP 200 OK
Figure70.Storeandforward:Message(s)differeddeliverywithasenderonline* *:CheckNOTES1,3and4insectionB.7
Page 144 of151
B.5 Store and forward: Message deferred delivery with sender offline
User A IM-AS
Messages stored: Msg1 ID1 Msg2 ID2 Msg3 ID3
IM-AS
User B is back online SIP INVITE (subject=msg1) CPIM (imdn.messageID=1) 180 RINGING SIP MESSAGE (no subject) CPIM (imdn.messageID=1, delivered) SIP INVITE (subject=msg2) CPIM (imdn.messageID=2) 180 RINGING SIP MESSAGE (no subject) CPIM (imdn.messageID=2, delivered) 603 DECLINE (previous invite) SIP 200 OK ACK MSRP SESSION established
User B
The session is closed when all stored messages are delivered, if the user writes a reply a new session is established Msg1 shown in pop-up
SIP INVITE (User B, p-Asserted-ID=rcse-standfw@<domain> a=sendonly) 480 TEMPORARILY UNAVAILABLE
SIP INVITE (User B, p-Asserted-ID=rcse-standfw@<domain> a=sendonly) 200 OK ACK MSRP SESSION established MSRP SEND CPIM (imdn.messageID=1, delivered) MSRP SEND CPIM (imdn.messageID=2, delivered)
MSRP SEND CPIM (imdn.messageID=1, displayed) MSRP SEND CPIM (imdn.messageID=2, displayed) MSRP SEND (msg3) CPIM (imdn.messageID=3) MSRP 200 OK MSRP REPORT CPIM (imdn.messageID=3) MSRP SEND CPIM (imdn.messageID=3, delivered)
Notifications stored: D&R ID1 D&R ID2 D&R ID3
MSRP SEND CPIM (imdn.messageID=3, delivered) MSRP SEND CPIM (imdn.messageID=3, displayed) SIP BYE SIP 200 OK
SIP BYE SIP 200 OK
Figure71.Storeandforward:Message(s)differeddeliverywithasenderoffline* *:CheckNOTE1insectionB.7
Page 145 of151
B.6 Store and forward: Notifications deferred delivery

User A IM-AS
Notifications stored: D&R ID1 D&R ID2 D&R ID3 SIP INVITE (User B, p-Asserted-ID=rcse-standfw@<domain> a=sendonly) SIP 200 OK ACK MSRP SESSION established SEND ONLY MSRP SEND CPIM (imdn.messageID=1, delivered) MSRP SEND CPIM (imdn.messageID=2, delivered) MSRP SEND CPIM (imdn.messageID=1, displayed) MSRP SEND CPIM (imdn.messageID=2, displayed) MSRP SEND CPIM (imdn.messageID=3, delivered) Msg3 delivered MSRP SEND CPIM (imdn.messageID=3, displayed) Msg3 read SIP BYE SIP 200 OK The session is closed when all stored notifications are delivered, if the user writes a reply a new session is established User A is back online
IM-AS
User B
Auto-accepts based on pAsserted-ID
Msg1 delivered Msg2 delivered
Msg1 read Msg2 read
Figure72.Storeandforward:Notification(s)differeddelivery* *:CheckNOTES1and4insectionB.7
Page 146 of151
B.7 Store and forward: Notes

PleasenotethefollowingnotesapplytodiagramsinAnnexB: NOTE1(B.1,B.2,B.3,B.4,B.5andB.6):200OKresponsestoSIPMESSAGEandMSRPSENDmessagesareomittedforclarity. NOTE2(B.3):Inamultidevicescenario,ifthedevicepublicGRUUinadeliverynotificationreceivedfromUserBisdifferentfrom the value for User As device used in the ongoing MSRP session, a new SIP INVITE using the new device public GRUU and P AssertedIdentitysettostandfwd@sip.rcse.comneedstobesenttowardsA. NOTE3(B.4):Inamultidevicescenario,ifthedevicepublicGRUUinadeliverynotificationadeliverynotificationreceivedafter thefirstINVITEissenttoUserAisdifferentfromthevalueinthefirstone,anewSIPINVITEwiththenewdevicepublicGRUU needstobesenttowardsA. NOTE4(B.3,B.4andB.6):ClarifythatBcouldhavetohandletwoincomingINVITEs,onefromtheIMserveronbehalfofAto deliverstoredmessagesandnotifications,andasecondonedirectlyfromAwhohappenstowanttochatwithBatthesametime. BshouldrecognizetheINVITEfromtheIMserveronbehalfofAandnottearitdownwhenthenewINVITEdirectlyfromAarrives. TheINVITEfromtheIMserveronbehalfofAwouldhavePAssertedIdentitysettotheIMserver(e.g.IMserver@<domain>,and ReferredBysettoA.
Page 147 of151
C. ANNEX C: RCS-e IM/Chat and multidevice

C.1 Delivery prior to acceptance
User A (device 1) User A (device 2) IMS Core Network User B (device 1) Msg1 shown in pop-up Send msg1 SIP INVITE (subject=msg1, pub-gruu=userA@device1 )) CPIM (imdn.messageID=1) 180 RINGING Notification ignored Msg1 delivered SIP MESSAGE (subject=notification, pub-gruu=userA@device1 ) CPIM (imdn.messageID=1, delivered) SIP INVITE (subject=msg2, pub-gruu=userA@device1 )) CPIM (imdn.messageID=2) 180 RINGING Msg2 delivered 603 DECLINE SIP MESSAGE (subject=notification, pub-gruu=userA@device1 ) CPIM (imdn.messageID=2, delivered) SIP INVITE (subject=msg1, pub-gruu=userA@device1 )) CPIM (imdn.messageID=1) 180 RINGING 180 RINGING SIP MESSAGE (subject=notification, pub-gruu=userA@device1 ) CPIM (imdn.messageID=1, delivered) Msg2 shown in pop-up SIP INVITE (subject=msg1, pub-gruu=userA@device1 )) CPIM (imdn.messageID=2) 180 RINGING 180 RINGING 603 DECLINE 603 DECLINE Msg2 shown in pop-up Msg1 shown in pop-up User B (device 2)
Send msg2
Notification ignored
SIP MESSAGE (subject=notification, pub-gruu=userA@device1 ) CPIM (imdn.messageID=2, delivered)
Figure73.IMandmultidevice:Deliverypriortoacceptance* *:CheckNOTES1and2insectionC.3
Page 148 of151
C.2 Post-acceptance behaviour

User A (device 1) User A (device 2) IMS Core Network User B (device 1) Msg1 shown in pop-up Send msg1 SIP INVITE (subject=msg1, pub-gruu=userA@device1 )) CPIM (imdn.messageID=1) 180 RINGING Notification ignored Msg1 delivered SIP MESSAGE (subject=notification, pub-gruu=userA@device1 ) CPIM (imdn.messageID=1, delivered) 200 OK ACK MSRP SESSION established Notification ignored SIP INVITE (subject=msg1, pub-gruu=userA@device1 )) CPIM (imdn.messageID=1) 180 RINGING 180 RINGING SIP MESSAGE (subject=notification, pub-gruu=userA@device1 ) CPIM (imdn.messageID=1, delivered) 200 OK SIP CANCEL ACK MSRP SESSION established Msg1 shown in pop-up User B (device 2)
Standard exchange as in Annex B.1
Standard exchange as in Annex B.1
Figure74.IMandmultidevice:Postacceptancebehaviour* *:CheckNOTES1and2insectionC.3
Page 149 of151
C.3 RCS-e IM/Chat and multidevice: Notes

PleasenotethefollowingnotesapplytodiagramsinAnnexB: NOTE1(C.1andC.2):200OKresponsestoSIPMESSAGEandMSRPSENDmessagesareomittedforclarity. NOTE 2 (C1 and C.2): As presented in section 2.14, the diagrams display the solution in a network supporting the pubgruu generation. For a network supporting the sip.instance tag only, would be equivalent but changing the relevant mechanism to carrythedeviceID(sip.instanceinsteadpubgruu).
Page 150 of151
D. ANNEX D: Authors
This document defines the RCSe specification jointly developed France Tlcom, Telefnica, Telecom Italia, Deutsche Telekom and Vodafone (group also known as MNO G5). This specification will be shared with other operators and suppliers with a view to launchingacommercialservicein2011. Contributors: JavierArenzanaArias(Telefnica) PhillipCarter(Vodafone) PatrickFroeller(DeutscheTelekom) scarGallegoGmez(Vodafone,documenteditor) SergioGarciaMurillo(Telefnica) YannGestraud(FranceTlcom/Orange) GonzaloGmezAcebo(Telefnica) AlfonsoGmezDaz(Vodafone) MarionLeGlau(FranceTlcom/Orange) JuanJosLozanoLozano(Telefnica) JonathonMarchant(Vodafone) RogelioMartnezPerea(Vodafone) ThibaudMienville(FranceTlcom/Orange) AntoniaNapolitano(TelecomItalia) SverinPasquereau(FranceTlcom/Orange) JeanPaulRodrigues(FranceTlcom/Orange) MartinShn(DeutscheTelekom) SilviaTessa(TelecomItalia) VincentTrocme(FranceTlcom/Orange) StphaneTuffin(FranceTlcom/Orange) FrancescoVadala(TelecomItalia) Finally and from this group, we would also like to thank the valuable contribution that many network, application and terminal/OEM vendors have provided via reviews, technicaladvisoryandcomments.
Page 151 of151

RCS e Advanced Comms Specification v1 1 Final

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

RCS e Advanced Comms Specification v1 1 Final

Enviado por

Direitos autorais:

Formatos disponíveis

RCSe AdvancedCommunications

RCSeAdvancedCommunications: ServicesandClientSpecification Version1.1 April08,2011

RCS Release 2 Specification Social profile information

RCS-e reference implementation

Communication Services information

Picture (Portrait) Icon Status text (Free text) Availability

IM/Chat File transfer Image share Video share

Discoverable & Interoperable

Additional technical specifications contained in this document

RCS-e is a simple interoperable service extension to voice & text today

Asaheadline,RCSeprovidesasimpleinteroperableextensiontovoiceandtexttoday. Theservicesaredesignedtorunoverdataandcanstandalone(e.g.Ishareapicturefrom themediagallery)orusedincombinationwithvoice(e.g.seewhatIseevideo).

1.1 RCS-e Principles

IM/chat Messages(SMS/MMS) Voice

1.2 OEM Integration

1.4 Scope and future evolution

2. Registration and capabilities discovery process

RCSeAdvancedComms: Servicesandclientspecification SIP Foralternativedigest USER/PASSWORD authenticationtoSSO/GIBA Mandatory parameter

Note1: Configuration parameters

Mandatory Parameter Mandatory Parameter Mandatory Parameter Mandatory Parameter

RCSEONLY APN FTWARNSIZE

RCSeAdvancedComms: Servicesandclientspecification shouldbealsoremoved.Pleasenotethatinthiscase,theRCSeinformationassociatedto contactsisnotbackedup.

2.2 Registration process

RCSeAdvancedComms: Servicesandclientspecification Phone Logic Client Logic MNOCore NW MNOIMSCore RCSAS

SIP200OKexpiryvalue providedbytheIMSCore SIPPUBLISH(capabilities)

ONLYIFENABLEDVIA CONFIGURATION Thepublicationonly happensiftheUSE PRESENCEparameterisset 1(seeTable5)

SIPOPTIONS(userB) SIP200OK(capabilitiesuserB) SIPOPTIONS(userC) ERROR480TEMPORARILYUNAVAILABLE/408REQUESTTIMEOUT SIPOPTIONS(userD) ERROR404NOTFOUND

Routed to/from userB

ConsistentlywithRCSRelease2specifications,theOMADMversionwhichshallbeimplementedforRCSe deviceconfigurationisOMADMversion1.2. 6 TheOMACPversionwhichshallbeimplementedforRCSedeviceconfigurationisOMACPversion1.1.

RCSeAdvancedComms: Servicesandclientspecification Enablingaconfigurationproceduretransparenttotheuser(OMACPdrawback) Reducingautodetectionmechanismcomplexity

UEUser/ClientA Phone Logic Client Logic

MNOCoreNW RCSe configserver

Currentversionis differentfromthe oneprovidedbythe client

alternative Server response

Theserverchecksiftheversionprovidedbytheclientmatchesthelatestversion oftheconfigurationavailableontheserver. Iftheversionmatches,theXMLwillbeempty:

SIPREGISTER SIP401UNAUTHORISED(challenge) SIPREGISTER(sec.header:USER andPASSWORD) SIP200OK(expiryvalue providedbytheIMSCore)

Restartreregistrationtimer ONLYIFENABLEDVIA CONFIGURATION Thepublicationonly happensiftheUSE PRESENCEparameteris set1(seeTable5)

SIPPUBLISH(capabilities,sec. header) SIP200OK

XCAPcanbealso authenticated.The recommendationisto usethesame USER+PASSWORD usedforSIP

XCAPXXX XCAP401UNAUTHORISED (challenge) XCAPXXX(Authheaderuser+pwd) XCAP200OK

2.3 Capability discovery

OPTIONSmessage mechanism.We areassumingUser BisREGISTERED, UserCisNOT REGISTEREDand UserDisNOTan RCSeuser

SIPOPTIONS(userB) SIP200OK(capabilitiesuserB) SIPOPTIONS(userC) ERROR480TEMPORARILYUNAVAILABLE/408REQUESTTIMEOUT Routed to/from SIPOPTIONS(userD) userB ERROR404NOTFOUND

ConsequentlywiththeRCSRelease2specification,thefollowingtagscanbeemployedto identifyimageandvideoshareservicecapabilities: RCSeservice Imageshare Videoshare Tag +g.3gpp.iariref="urn%3Aurn7%3A3gppapplication.ims.iari.gsmais" +g.3gpp.csvoice

SIPANONYMOUSSUBSCRIBE (userB,exp=0) SIP200OK SIPNOTIFY(UserBcapabilities)

2.4 New user discovery mechanism

UEUser/ClientB Client Logic

Otherwisewereceiveanerror.In thiscasetheuserisinitiallynot identifiedasaRCSuser

XCAPGET(userA_contact_list) XCAP 200OK(contact_list) or404NOTFOUND XCAPPUT(userA_contact_list) XCAP200OK or 404NOTFOUND Figure15.UpdatingtheXDMSlistofcontactssupportingsocialinformationviapresencefunctionality

2.5 Capability polling mechanism

OPTIONSmessage mechanism.We areassumingUser BisREGISTERED, UserCisNOT REGISTEREDand UserDisNOTan RCSeuser

SIPOPTIONS(userB) SIP200OK(capabilitiesuserB) SIPOPTIONS(userC) ERROR480TEMPORARILYUNAVAILABLE/408REQUESTTIMEOUT SIPOPTIONS(userD) ERROR404NOTFOUND

Routed to/from userB

Notethelistpreviously storedintheXDMSis usedforthisquery (userA_contact_list)

SIPANONYMOUSSUBSCRIBE (userA_contact_list,exp=0) SIP200OK SIPNOTIFYs(RLSresponse)

SIP200OK SIPNOTIFYs(capabilitiesper RCSregistereduser;aggregated response)

BoththeRLSresponse andsubsequent response(s)shouldbe combinedtogetthe completeresponse

REGISTER PUBLISH<CAPABILITIES> SendOPTIONStoallcontacts

SendOPTIONSto new/modified contacts UPDATEXDMS<list> (PRESENCEDISCOVERY=1and forcontactswithdiscovery presencetaginOPTIONS)

OPTIONStoallcontacts whosecapabilitieshave notbeenrecentlyupdated

LIVECAPABILITY/SERVICEDISCOVERY(Performedwhenacommunicationis likelytohappenortoupdatestatuswithinanexistingcommunication)) OPTIONS<contact> Figure18.RCSecapabilityandnewuserdiscoverymechanisms20

2.6 Management of supplementary RCS functionality

2.7 RCS-e and capabilities

MNO MNO choice choice MNO MNO choice choice

One way only