RCS Registration is usually handled by the IMS automatically when a user that is authorised RCS Services registers to the IMS with a UE that supports RCS Services.

The Figure 7.13.2-1 without the CC-POI in the RCS Server provides the architecture for LI for capability discovery. In a normal deployment, the S-CSCF, a Presence Server or Messaging Server may perform the function of the RCS Server in Figure 7.13.2-1.

The capability or service discovery mechanism in RCS is a process which enhances service usability by allowing a RCS user to exchange its own RCS service capabilities and to understand the RCS service capabilities of another RCS user, at certain points in time. When available, the RCS specification provides two alternative mechanisms to perform the capability discovery:

• SIP OPTIONS exchange: The SIP OPTIONS end-to-end message is used by one RCS user (e.g., User A) to query the capabilities (services which the other user has available) of the other RCS user (e.g., User B). The SIP OPTIONS message passes the information about which capabilities are supported by User A and the response contains information about which capabilities are supported by User B. Using this method, both users get updated information in a single transaction.
• Presence: In this case, instead of performing an end-to-end transaction, the capabilities are queried against a presence server which is part of the RCS Server as defined in GSMA RCC.07 [35] clause 2.6.1.2.

When the SIP OPTIONS request is used, user A includes user A's RCS capabilities and the IMPU of user B. The response is any of the following:

• SIP 200 OK including at least, one of the tags assigned to the RCS Services. User B is an RCS user. The capabilities returned in the SIP 200 OK response are considered as the current communication options with user B.
• SIP 200 OK not including any of the tags used by RCS services. User B is registered to IMS, but not with an RCS client. User B is not an RCS user. Only the non-RCS communication services (e.g. voice calls, SMS, MMS, etc.) are indicated as available.
• SIP 480 TEMPORARY UNAVAILABLE or 408 REQUEST TIMEOUT returned by the network if user B is an IMS (and potentially thus an RCS) user, but is currently not registered.
• 404 Not Found or 604 Does Not Exist Anywhere. User B is not considered as an IMS user nor an RCS user. Only the non-RCS communication services (e.g., voice calls, SMS, MMS, etc.) are indicated as available.

When presence is used:

• After user A has registered to IMS, User A publishes their RCS capabilities in a Presence document that is published by using the SIP PUBLISH request. If changes are required in the published capabilities (e.g., due to RAT change), a new PUBLISH request is sent. When the client/device is switched off, the published capabilities are removed from the presence server before deregistering from IMS by sending another PUBLISH request.
• When User A wants to use RCS, User A requests the RCS capabilities of user B by sending SIP SUBSCRIBE requests. The Presence server of User B sends a SIP NOTIFY request to User A containing the RCS capabilities of User B.

The Figure 7.13.2-1 without the CC-POI in the RCS Server provides the architecture for LI for capability discovery. In a normal deployment, if SIP OPTIONS are used for capability discovery, the Messaging Server performs the function of the RCS Server in Figure 7.13.2-1. In a normal deployment, if presence is used for capability discovery, the presence server and S-CSCF performs the function of the RCS Server in Figure 7.13.2-1.

Standalone messaging is based on the OMA CPM Pager Mode and Large Message Mode mechanisms as described in OMA CPM [34]. When the size of a message does not exceed 1300 bytes, it can be sent as a pager mode standalone message carried directly within the body of a SIP MESSAGE. It may be sent to one or many destinations. Using the SIP MESSAGE method, the message body is CPIM-formatted message as specified in RFC 3862]. The SIP/IP Core provides the routing between the RCS Server and RCS Clients without establishing a SIP session. The origination of the pager mode standalone message may request to receive a disposition status notification when the message is delivered and/or displayed to the destination of the message. If sent, these messages will follow the reverse path indicated in the message they relate to. These messages may be used for 1-to-1 or 1-to-many pager mode messaging and the notification details are carried within the body of a SIP MESSAGE. If a standalone message is larger than 1300 bytes, large message mode is used. In large message mode, the contents of the message are not inserted into the SIP message but carried using MSRP as defined in RFC 4975 and RFC 6714. A SIP session is established between the interested parties (sender and all receivers) with MSRP as the media Stream. The CPIM-formatted messages are then transmitted using MSRP data chunks. Large Message Mode SIP sessions should not be confused with a chat session as no chat session is established. The SIP session is only used to transmit exactly one large message after which the SIP session is torn down. If delivery and/or display notifications need to be returned by the recipient(s), these notifications are CPIM-formatted messages carried within MSRP data chunks inside the SIP session or within SIP MESSAGEs delivered outside the SIP session as pager mode messages.

The Figure 7.13.2-1 provides the architecture for LI for pager mode standalone messaging. In a normal deployment, the P-CSCF or S-CSCF perform the function of the RCS Server in Figure 7.13.2-1.

The RCS 1-to-1 chat service and group chat service use SIP procedures for the setup of chat sessions and MSRP for the exchange of user messages as defined in RCC.07 [35] clause 3.2.3. Each MSRP SEND request containing a user message contains a request to receive a delivery notification and possibly a display notification. The client therefore always includes the header field for delivery notification when sending a message. The notifications may be delivered within the 1-to-1 chat session as MSRP SEND requests or outside the 1-to-1 chat session as a pager mode message delivery notification. Multimedia content is not permitted in user messages. Only text/plain user messages can be exchanged. For the establishment of a group chat session, an RCS user selects at least 2 contacts capable of the chat service. Only ad-hoc groups are authorized. An ad-hoc group is a list of addresses created by the target dynamically. Pre-defined group are not permitted. Extending of a 1-to-1 chat to a group chat is not applicable for the current version of the RCS specification. Users may dynamically add additional participants to a group chat, if they are capable to support chat service.

The Figure 7.13.2-1 provides the architecture for LI for 1-to-1 chat.

When an RCS user desires to send a file to one or more other RCS users, the file URL transfer service is used. The user first uploads the file to a HTTP Content Server, and then uses pager mode standalone messaging, large message mode standalone messaging, 1-to-1 Chat or group chat procedures described in clauses D.4 and D.5 respectively to send the URL of the file to the recipient(s). When using pager mode standalone messaging, the originating client sends the URL of the file in a SIP MESSAGE as a CPIM-formatted message. When using large message mode standalone messaging, 1-to-1 chat or group chat the originating client sends the URIL of the file in MSRP data chunk. The originating client may request delivery and/or display notification to the recipient(s). If the recipients send status notification(s), they are sent as CPIM-formatted messages and may be delivered by the recipient in a SIP MESSAGE when using pager mode standalone messaging and in an MSRP data chunk when using large message mode standalone messaging, 1-to-1 chat or group chat.

The Figure 7.13.2-1 provides the architecture for LI for file transfer.