Rich Communications Suite enhanced (RCS-e) is a GSMA specification that enables different types of communication services prioritising the interoperability of the services across network operators and handset manufacturers. These services or features can be summarised as: Presence (user available, unavailable, on a call . . . ), Instant Messaging, Video Share and File Transfer. All based on IMS using SIP protocol.
In the specification of RCS-e there are two mechanisms to discover whether another user is also a subscriber of the service, and also his/her capabilities (which features are available to share with them):    1) Presence Server mechanism: when a new contact is added to the address book (resource list) an anonymous SUBSCRIBE message is sent to the new user. This SUBSCRIBE message reaches a Presence Server in the other user's network, and based on this user presence rules (if he allows this type of method) the Presence Server replies to this SUBSCRIBE message with a NOTIFY message informing of the RCS capabilities of the user to the originator of the SUBSCRIBE message.
The problem with this first approach is that presence is an expensive service due to hardware, licenses and network infrastructure.    2) Peer to peer mechanism: the user can send an OPTIONS message with its capabilities to an address-book contact to query its capabilities in real time. When the OPTIONS arrives at the other user it will reply with a 2000 K message containing its capabilities. This way, user A is able to know if user B can support a video session (and vice versa) and therefore start it or not.
This second first approach is based on the SIP OPTIONS message, a peer-to-peer message exchanged between clients.
This mechanism is based in the use of tags (each tag is a string that represents a service) contained and transported in the Accept-contact and Contact headers for the SIP OPTIONS, and its responses are:
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 Accept-contact headers of the SIP OPTIONS message.
The tags corresponding to the subset of functionalities that are supported by the receiving terminal are included in the Contact header of the 200 OK response.
This SIP OPTIONS message is sent in the following scenarios to discover whether a contact is capable of sharing some services:
The first time the service is enabled on the device of user A (note that one SIP OPTIONS message is sent per IMS identity stored in the address book of that user A device);
when a new contact is added to the phone address book; or
whenever user A interacts with that contact.
Whenever a SIP OPTIONS message is sent from user A to user B, user A receives one of two types of response:    1) If user B is registered, then the response from user B's client comprises the CAPABILITY STATUS—the set of services currently available for user B, which are added as feature tags in the OPTIONS message.
The situation of case 1) is shown in FIG. 1:
User A and user B have the capabilities for registering at IMS via respective access networks 21, 11. Both IMS networks are interconnected 101.
User A's client 20 sends a SIP OPTIONS message to user B's client 10 to discover user B's capabilities (step 1001). This message is sent via an IMS network 200 of the mobile network operator MNO of user A.
This message reaches an I-CSCF 110 of an IMS network 100 of the mobile network operator MNO of user B. The I-CSCF 110 sends a DIAMETER Location-Info-Request message via the Cx interface to the corresponding HSS 130 (step 1002).
The HSS 130 responds with a Location-Info-Answer message to the I-CSCF 110 with the information of the S-CSCF 120 where user B is located (step 1003).
The I-CSCF 110 forwards the SIP OPTIONS message to the S-CSCF 120 (step 1004a), which sends the message to user B's client 10 (step 1004b).
User B's client 10 responds to this SIP OPTIONS message with a 200 OK message which includes the service tags corresponding to the subset of the functionalities that are supported by user B, which message reaches user A's client 20 (steps 1005a, 1005b, 1005c).    2) If user B is currently not registered (for instance, user B's phone is off), then the network responds with the following message error: 480 TEMPORARILY UNAVAILABLE (graceful deregistration took place).
Or if the end point of user B is registered but not reachable (e.g. sudden switch off of user B's device due to low battery or coverage drops) the OPTIONS message does not reach user B's terminal, and therefore there is no response. The OPTIONS request will timeout in a core node, implying a 408 REQUEST TIMEOUT message towards user A's device.
This case is shown in FIG. 2:
User A's client 20 sends a SIP OPTIONS message to user B's client 10 to discover the capabilities of user B (step 1006).
This message reaches the I-CSCF 110, which sends a Location-Info-Request message via the Cx interface to the corresponding HSS 130 (step 1007).
The HSS 130 responds with a Location-Info-Answer message to the I-CSCF 110 with the information of the S-CSCF 120 where user B is located (step 1008).
The I-CSCF 110 forwards the SIP OPTIONS message to the S-CSCF 120 (step 1009).
But since user B is either not registered or not reachable, user A's client 20 receives an error message, either a 480 TEMPORARILY UNAVAILABLE or a 408 REQUEST TIMEOUT (step 1010).
Note that from a user experience perspective the two situations described under 2) above are inconclusive, and since there are no service tags in the response no RCS-e services will be shown to user A as available to communicate with user B.
Two problems arise here:
User A will not be aware that user B has the same services that he/she has. Then user A will not try to communicate with user B. User A will need to start a new service discovery process when user B is registered to discover its services, but A is unable to know when to start this process again.
Also note that there are a set of “offline services”. These are services that do not require user B to be online to be executed. An example of these services is the chat service when the feature Store and Forward is available (when user B is not reachable, messages are stored by the network and then sent to user B once it REGISTERS again in the IMS network). Then there is no need to wait for user B to be registered to show the service availability.
Thus, the existing solution for discovering capabilities poses a technical problem, since user A is unable to understand the subset of services that this user A is available to access and/or communicate with his/her contacts at certain point in time.
USPTO Backgrounds
USPTO Backgrounds