Patent Description:
Conventionally, a Mobile Originated (MO) has to negotiate with a Mobile Terminated (MT) after establishing a call between the MO and the MT , to know In-Call capability features of the MT such as a shared sketch, a shared map etc..

Due to various timing issue in signalling the In-Call capability features of the MO and the MT after establishing the call, the MO and the MT do not properly display the call and the In-Call capabilities to the user. In case of a communication between the MO and the MT in a slow network, the SIP messages may be jumbled up. Therefore, the MO and the MT receives the SIP messages totally in a non-sequential manner, which further leads the MO and the MT to operate in an unpredictable manner. Therefore, signalling of a large amount of SIP messages for every call session is unfavourable for identifying the In-Call capability features of the MO and the MT. Moreover, signalling of the large amount of SIP messages consumes network traffic in large amount.

In case of a SUBSCRIBE, PUBLISH, AND NOTIFY capability exchange network, the In-Call capability features are not defined by Mobile Communications Association (GSMA). However, communicating the In-Call capability features of the MO and the MT is desirable in the SUBSCRIBE, PUBLISH, AND NOTIFY capability exchange network.

In hybrid networks, the MO supports a PRESENCE way of capability discovery and the MT supports OPTIONS way of capability discovery and vice versa. Conventional methods does not define steps for handling the signalling messages in the hybrid networks for capability discovery of the MO and the MT due to complexity in using the PRESENCE way and the OPTIONS way together for the capability discovery.

Thus, it is desired to address the above mentioned shortcomings or at least provide a useful alternative.

<CIT> discloses an electronic device. The electronic device may comprise: a communication circuit for supporting a cell function, a memory for storing a database including contacts of a plurality of users, wherein the database contains a plurality of contact groups and a first user of the plurality of users belongs to a first contact group; and a processor configured to cause the communication circuit to transmit, to a user terminal of the first user, a request for a profile call, which comprises a contact of the first user and information on images corresponding to the first contact group, when a user input to send a call to send a call to the first user is received.

<CIT> discloses a method to transfer control. The method includes sending a message requesting transfer of control of a collaborative session, and receiving notification, in response to the sent message, indicative of a transfer result of said requested transfer of control. The method may include, when the transfer result in the received notification indicates success, relinquishing control of the collaborative session. The method may include maintaining control of the collaborative session independent of the transfer result in the received notification. The message requesting transfer of control of a collaborative session may also comprises a request for media transfer.

The embodiments herein is to provide a method and apparatus for identifying In-Call capability features without dedicated capability discovery procedure.

The embodiments provide an efficient method for identifying In-Call capability features in a communication system.

This method and apparatus is illustrated in the accompanying drawings, throughout which like reference letters indicate corresponding parts in the various figures. The embodiments herein will be better understood from the following description with reference to the drawings, in which:.

As is traditional in the field, embodiments may be described and illustrated in terms of blocks which carry out a described function or functions. These blocks, which may be referred to herein as managers, units, modules, hardware components or the like, are physically implemented by analog and/or digital circuits such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hardwired circuits and the like, and may optionally be driven by firmware and software. The circuits may, for example, be embodied in one or more semiconductor chips, or on substrate supports such as printed circuit boards and the like. The circuits constituting a block may be implemented by dedicated hardware, or by a processor (e.g., one or more programmed microprocessors and associated circuitry), or by a combination of dedicated hardware to perform some functions of the block and a processor to perform other functions of the block. Each block of the embodiments may be physically separated into two or more interacting and discrete blocks without departing from the scope of the disclosure. Likewise, the blocks of the embodiments may be physically combined into more complex blocks without departing from the scope of the disclosure.

The embodiments herein provide a method for identifying In-Call capability features without dedicated capability discovery procedure. The method includes sending, by a MO(Mobile Originated), a call request message to a MT(Mobile Terminated). Further, the call request message includes the In-Call capability features of the MO. Further, the method includes receiving, by the MO, a call response message from the MT, Further, the call response message includes the In-Call capability features of the MT. Further, the method includes performing, by the MO, In-Call capability negotiation with the MT.

Unlike exiting methods and systems, the proposed method can be used to exchange the In-Call capability features between the MO and the MT within less number of signaling messages. Therefore, a jumbling up of SIP(Session Initiation Protocol) messages in a slow network can be avoid by employing the proposed method in the slow network, due to exchanging reduced number of signaling messages.

Based on the proposed method, the MO and the MT exchanges the In-Call capability features while establishing a call. Therefore, a timing issue in signalling the In-Call capability features of the MO and the MT after establishing the call in the existing system can be solved by employing the proposed method.

An established call between the MO and the MT can hold and resume by sending less number of signaling messages between the MO and the MT based on the proposed method. Therefore, the MO and the MT consumes only a less amount of network traffic for exchanging the In-Call capability features, holding and resuming the call etc., while comparing to the existing methods and systems. The proposed method also have a flexibility to employ in a SUBSCRIBE, PUBLISH, AND NOTIFY capability exchange network, a network that supports OPTIONS way of capability exchange as well as in hybrid networks for exchanging the In-Call capability features of the MO and the MT.

That is, the MO and the MT in a SUBSCRIBE, PUBLISH, AND NOTIFY capability exchange network, in a network that supports OPTIONS way of capability exchange or in a hybrid network performs an proposed method of the disclosure. In other words, the proposed method disclosed herein may be performed in a SUBSCRIBE, PUBLISH, AND NOTIFY network, a network that supports OPTIONS way of capability exchange or a hybrid network.

Furthermore the identification of the In-Call capability features without dedicated capability discovery procedure is used in a SUBSCRIBE, PUBLISH, AND NOTIFY network, a network that supports OPTIONS way of capability exchange and a hybrid network, according to the present disclosure.

Furthermore, the In-Call capability features are identifying withut performing a dedicated capability discovery procedure, according to the present disclosure.

According to the present disclosure, In-Call capability features may be information regarding In-Call capability features. Furthermore, the information regarding In-Call capability may include information regarding whether the MO or the MT is capable of sharing content(such as map, sketch, presentation, chat, location, video, audio, files or group of files), but not limited thereon. Furthermore, In-Call capability features may includes Pre-call capability and Post -call capability.

A MO <NUM> and a MO <NUM> are similar devices which operate as a mobile originated, whereas the MO <NUM> may include novel hardware elements which describe in the embodiments of the disclosure. A MT <NUM> and a MT <NUM> are similar devices which operate as a mobile terminated, whereas the MT <NUM> may include novel hardware elements which describe in the embodiments of the disclosure.

The MO <NUM>, MO <NUM>, MT <NUM>, and MT <NUM> can be, for example, but not limited to a cellular phone, a smart phone, a Personal Digital Assistant (PDA), a tablet computer, a laptop computer, a smart social robot, a smart watch, a music player, a video player, an Internet of things (IoT) device or the like.

<FIG> is a sequential diagram illustrating signalling of Session Initiation Protocol (SIP) messages between the MO <NUM> and the MT <NUM> to identify the In-Call capability features by performing OPTIONS way of capability discovery.

In operation A101, the MO <NUM> may send a call request message (i.e. INVITE message) to the MT <NUM> for connecting to the MT <NUM>. In operation A102, the MT <NUM> may send a call response message (i.e. <NUM> OK message), in response to connecting to the MO <NUM>.

In operation A103, the MO <NUM> may send an acknowledgment to the MT <NUM>, in response to receiving the call response message. In operation A104, the MO <NUM> may send OPTIONS message to the MT <NUM> for indicating the In-Call capability features of the MO <NUM> to the MT <NUM>, where a contact header of the OPTIONS message may include the In-Call capability features of the MO <NUM>.

In operation A105, the MT <NUM> may acknowledge with the <NUM> OK message to the MO <NUM>, in response to receiving the OPTIONS message from the MO <NUM>. In operation A106, the MT <NUM> may send OPTIONS message to the MO <NUM> for indicating the In-Call capability features of the MT <NUM> to the MO <NUM>, where the contact header of the OPTIONS message may include the In-Call capability features of the MT <NUM>.

In operation A107, the MO <NUM> may acknowledge with the <NUM> OK message to the MT <NUM>, in response to receiving the OPTIONS message from the MT <NUM>. Therefore, at least two OPTIONS messages are consumed for each connected call, to know the In-Call capability features of the MO <NUM> and the MT <NUM>.

<FIG> is a sequential diagram illustrating signalling of the SIP messages between the MO <NUM> and the MT <NUM> for holding the connected call.

The MO <NUM> has to negotiate with the MT <NUM> to hold/resume a connected call. In operation B101, the MO <NUM> may send the call request message (i.e. INVITE message) to the MT <NUM> for connecting to the MT <NUM>. In operation B <NUM>, the MT <NUM> may send the call response message (i.e. <NUM> OK message), in response to connecting to the MO <NUM>.

In operation B103, the MO <NUM> may send the acknowledgment to the MT <NUM>, in response to receiving the call response message. In operation B104, the MO <NUM> may send OPTIONS message to the MT <NUM>, indicating that the MO <NUM> wants to hold the connected call, where the contact header of the OPTIONS message may not include the In-Call capability features of the MO <NUM>.

In operation B105, the MT <NUM> may acknowledge with the <NUM> OK message to the MO <NUM>, in response to receiving the OPTIONS message from the MO <NUM>. In operation B106, the MT <NUM> may send OPTIONS message to the MO <NUM>, indicating that the MO <NUM> is ready to hold the connected call, where the contact header of the OPTIONS message may not include the In-Call capability features of the MT <NUM>.

In operation B107, the MO <NUM> may acknowledge with the <NUM> OK message to the MT <NUM>, in response to receiving the OPTIONS message from the MT <NUM>. Therefore, at least two OPTIONS messages are consumed for each connected call, to hold the call. Also, similar number of steps as mentioned for holding the call is required to resume the call.

<FIG> is a block diagram of the MO <NUM> for identifying In-Call capability features without dedicated capability discovery procedure, according to an embodiment of the disclosure.

Examples for the MO <NUM> are, but not limited to a smart phone, a tablet computer, a personal computer, a personal digital assistance (PDA), an Internet of Things (IoT) or the like. In an embodiment, the MO <NUM> may include, but not limited to a processor <NUM>, a memory <NUM> and a communicator <NUM>. In an embodiment, the processor <NUM> may include an In-Call capability message indicator <NUM> and an In-Call capability negotiator <NUM>. The processor <NUM> may be coupled to the memory <NUM> and the communicator <NUM>. The processor <NUM> may be configured to send a call request message to the MT <NUM>. The call request message may include the In-Call capability features of the MO <NUM>. That is, information regarding In-Call capability features of the MO may be included in the call request message.

In an embodiment, the call request message may a SIP INVITE message (also called as an INVITE message). An example for the SIP INVITE message based on proposed solution is given below, but not limited to thereon:
To:<sip:+<NUM>@ims. mcc405.3gppnetwork. org;user=phone>
From: <tel:+<NUM>>;tag=82b79c35
CSeq: <NUM> INVITE
Session-Expires: <NUM>-SE: <NUM>
Contact: <sip:<NUM>@[<NUM>:<NUM>:5e00:ced7::81b:30b0]:<NUM>>;
sip. instance="<urn:gsma:imei:<NUM>-<NUM><NUM>>";q=<NUM>;+g. icsi-ref="urn%3Aurn-
<NUM>%3A3gpp service. mmtel,urn%3Aurn-<NUM>%3A3gpp
service. callcomposer,urn%3Aurn-<NUM>%3A3gpp-
service. sharedmap,urn%3Aurn-<NUM>%3A3gpp-
service. sharedsketch,urn%3Aurn-<NUM>%3A3gpp-
service. callunanswered";video;+g. iari-
ref="urn%3Aurn-<NUM>%3A3gpp-application. im,urn%3Aurn-<NUM>%3A3gpp-
application. fullsfgroupchat,urn%3Aurn-<NUM>%3A3gpp-
application. ft,urn%3Aurn-<NUM>%3A3gpp-application. fthttp,urn%3Aurn-
<NUM>%3A3gpp-application. ftthumb,urn%3Aurn-<NUM>%3A3gpp-application. gsma-
is,urn%3Aurn-<NUM>%3A3gpp-application. intmsg,urn%3Aurn-<NUM>%3A3gpp-
application. geopush"
Accept: application/sdp
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, UPDATE, INFO, REFER, NOTIFY,
MESSAGE, PRACK
Content-Type: multipart/mixed;boundary=ca2c5e7adb09165e
Supported: timer, sec-agree
User-Agent: Samsung_SM-G960F_G960FXXE1BRD3_IMS_6. <NUM>
P-Preferred-Identity: <tel:+<NUM>>
Accept-Contact: *;+g.

In an embodiment. the processor <NUM> may send the call request message to the MT <NUM>. The In-Call capability message indicator <NUM> may send the call request message to the MT <NUM>. The processor <NUM> may be configured to receive a call response message from the MT <NUM>. The call response message may include the In-Call capability features of the MT <NUM>. In other words, information regarding In-Call capability features of the MT may be included in the call response message.

In an embodiment, the call response message may a SIP INVITE <NUM> OK message (also called as a <NUM> OK message). An example for the SIP INVITE <NUM> OK message based on the proposed solution is given below, but not limited to thereon:
Via: SIP/<NUM>/TCP [<NUM>:<NUM>:5c89:<NUM>::172f:f0a0]:<NUM>;branch=z9hG4bK-<NUM>-<NUM>---
Contact: <sip:<NUM>-
<NUM>@ka1wcas0019rcs. mcc405.3gppnetwork. org:<NUM>;fid=server_1>;+si
p. instance="<urn:gsma:imei:<NUM>-<NUM>-<NUM>>";+g. icsi-ref="urn%3Aurn-<NUM>%3A3gpp-
service. mmtel,urn%3Aurn-<NUM>%3A3gpp-service. callcomposer,urn%3Aurn-
<NUM>%3A3gpp-service. sharedmap,urn%3Aurn-<NUM>%3A3gpp-
service. sharedsketch,urn%3Aurn-<NUM>%3A3gpp-
service. callunanswered";+g. iari-
ref="urn%3Aurn-<NUM>%3A3gpp-application. im,urn%3Aurn-<NUM>%3A3gpp-
application. fullsfgroupchat,urn%3Aurn-<NUM>%3A3gpp-
application. ft,urn%3Aurn-<NUM>%3A3gpp-application. fthttp,urn%3Aurn-
<NUM>%3A3gpp-application. ftthumb,urn%3Aurn-<NUM>%3A3gpp-application. gsma-
is,urn%3Aurn-<NUM>%3A3gpp-application. intmsg,urn%3Aurn-<NUM>%3A3gpp-
application. geopush";video
To:<sip:+<NUM>@ims. mcc405.3gppnetwork. org;user=phone>;tag=jfs1
h7dv-4z613v
From: <tel:+<NUM>>;tag=<NUM>
Call-ID: 0sDiHD7RI_Lzgwj-vzrizg. @<NUM>:<NUM>:5c89:<NUM>::172f:f0a0
CSeq: <NUM> INVITE
Session-Expires: <NUM>;refresher=uac
Content-Type: application/sdp
Server: IM-serv/OMA1. <NUM> WCAS
Content-Length: <NUM>.

In an embodiment. the processor <NUM> may receive the call response message from the MT <NUM>. In an embodiment, the In-Call capability message indicator <NUM> may receive the call response message from the MT <NUM>. The processor <NUM> may be configured to perform the In-Call capability negotiation with the MT <NUM>. In an embodiment, the In-Call capability negotiator <NUM> may perform the In-Call capability negotiation with the MT <NUM>.

In an embodiment, the MO <NUM> may indicate the In-Call capability features in a contact header of the call request message when the MO <NUM> supports a VOLTE(Voice Over Long Term Evolution) and a RCS(Rich Communication Suite) on a single PDN(Packet Data Network) and the MT <NUM> support the VOLTE and the RCS on a single PDN.

Furthermore, In an embodiment, the MO <NUM> may indicate the In-Call capability features in a SIP private extension header of the call request message when the MO <NUM> supports the VOLTE and the RCS on the single PDN, and the MT <NUM> supports the VOLTE on a first PDN and the RCS on a second PDN.

Furthermore, In an embodiment, the MO <NUM> may indicate the In-Call capability features in the SIP private extension header of the call request message when the MO <NUM> supports the VOLTE on the first PDN and the RCS on the second PDN, and the MT <NUM> supports the VOLTE and the RCS on the single PDN.

Additionally, In an embodiment, the MO <NUM> may indicate the In-Call capability features in the SIP private extension header of the call request message when the MO <NUM> supports the VOLTE on the first PDN and the RCS on the second PDN, and the MT <NUM> supports the VOLTE on the first PDN and the RCS on the second PDN.

*<NUM> Additionally, In an embodiment, In-Call capability features of a device may be discovered based on a device registration type, where the device is the MO <NUM> or the MT <NUM>. The type of device registration can be a single registration or a dual registration.

In an embodiment, in the single registration, the VOLTE and the RCS may be registered on a single PDN for a same International Mobile Subscriber Identity (IMSI) or Mobile Subscriber Integrated Services Digital Network (MSISDN). In the dual registration, the VOLTE and the RCS may be registered on a different PDN for the same IMSI or MSISDN.

In an embodiment, when the MO <NUM> and the MT <NUM> have the single registration, then the In-Call capability features may negotiate in the contact header of the SIP INVITE message. In an embodiment, when the MO <NUM> has the single registration and the MT <NUM> has the dual registration, then the SIP INVITE message may include the SIP private extension header with the In-Call capability features. In an embodiment, when the MO <NUM> and the MT <NUM> have the dual registration, then the SIP INVITE message may include the SIP private extension header with the In-Call capability features.

In an embodiment, the MO <NUM> may generate the SIP private extension header for identifying the In-Call capability features in the dual registration. The SIP private extension header may include all the In-Call capability features supporting by the MO <NUM>. Further, the MO <NUM> may add the SIP private extension header in the SIP INVITE message to convey the MT <NUM> that the MO <NUM> is RCS registered and supports in the In-Call capability features. If the MT <NUM> is registered to the RCS, then the MT <NUM> may parse the SIP private extension header and may add the In-Call capability features of the MT <NUM> in the same SIP private extension header. Further, the MT <NUM> may reply the SIP INVITE <NUM> OK message including the updated SIP private extension header. Further, the device may activate the In-Call capability features based on the request/response for the In-Call capability features.

In an embodiment, the SIP private extension header may be defined as P- Associated-Features. Consider the device may be registered to the RCS & In-Call capability features. While initiating the call, the MO <NUM> may send the SIP INVITE message to the MT <NUM> by adding the SIP private extension header "P- Associated-Features" with all the supported "In-Call capability features". An example for the SIP INVITE message is given below, but not limited to thereon:
[-->] INVITE <sip:+<NUM>@ims. mcc405.3gppnetwork. org> SIP/<NUM>
[CSeq: <NUM> INVITE]
Via: SIP/<NUM>/TCP [<NUM>:<NUM>:5cld:bla2::b9c:70a4]:<NUM>;branch=z9hG4bK-<NUM>-<NUM>---
2be20f84ddae419c;rport;transport=TCP
Max-Forwards: <NUM>
Route: <sip:[<NUM>:<NUM>:<NUM>:<NUM>::<NUM>]:<NUM>;1r>
Proxy-Require: sec-agree
Require: sec-agree
Contact:<sip:+<NUM>@[<NUM>:<NUM>:5c1d:b1a2::b9c:70a4]:<NUM>>;+sip. instance="
<urn:gsma:imei:<NUM>-<NUM>-<NUM>>";+g. icsi-ref="urn%3Aurn-<NUM>%3A3gpp-
service. mmtel";video
P- Associated-Features : +g. icsi-ref= "urn%3Aurn-<NUM>%3A3gpp-
service. sharedmap,urn%3Aurn-<NUM>%3A3gpp-
service. sharedsketch,urn%3Aurn-<NUM>%3A3gpp-
service. callunanswered".

The MT <NUM> checks the SIP private extension header and returns "In-Call capability features" of the MT <NUM> in the SIP INVITE <NUM> OK message. Along with a session negotiation, the In-Call capability negotiation will also be carried out. An example for the SIP INVITE <NUM> OK message is given below:
<-- <NUM> OK INVITE <sip:+<NUM>@ims. mcc405.3gppnetwork. org>
SIP/<NUM> [CSeq: <NUM> INVITE]
Via: SIP/<NUM>/TCP
[<NUM>:<NUM>:5c1d:b1a2::b9c:70a4]:<NUM>;branch=z9hG4bK-<NUM>-<NUM>---
2be20f84ddae419c;rport;transport=TCP
Max-Forwards: <NUM>
Route: <sip:[<NUM>:<NUM>:<NUM>:<NUM>::<NUM>]:<NUM>;1r>
Proxy-Require: sec-agree
Require: sec-agree
Contact:<sip:+<NUM>@[<NUM>:<NUM>:5c1d:b1a2::b9c:70a4]:<NUM>>;+sip. instance="
<urn:gsma:imei:<NUM>-<NUM>-<NUM>>";+g. icsi-ref="urn%3Aurn-<NUM>%3A3gpp-
service. mmtel";video
P- Associated-Features : +g. icsi-ref= "urn%3Aurn-<NUM>%3A3gpp-
service. sharedmap,urn%3Aurn-<NUM>%3A3gpp-
service. sharedsketch,urn%3Aurn-<NUM>%3A3gpp-
service. callunanswered".

The processor <NUM> may be configured to execute instructions stored in the memory <NUM>. The memory <NUM> may include non-volatile storage elements. Examples of such non-volatile storage elements may include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of an Electrically Programmable Memory(EPROM) or an Electrically Erasable and Programmable Memory(EEPROM).

In addition, the memory <NUM> may be considered a non-transitory storage medium. The term 'non-transitory' may indicate that the storage medium is not embodied in a carrier wave or a propagated signal. However, the term 'non-transitory' should not be interpreted that the memory <NUM> is non-movable.

In an embodiment, the memory <NUM> can be configured to store larger amounts of information than the memory <NUM>. For example, a non-transitory storage medium may store data that can, over time, change (e.g., in Random Access Memory (RAM) or cache), but not limited to thereon.

The communicator <NUM> may be configured to communicate internally between hardware components in the MO <NUM>. Further, the communicator <NUM> may be configured to communicate the MO <NUM> to the MT <NUM>.

In an embodiment, the identification of the In-Call capability features without dedicated capability discovery procedure may be used in a SUBSCRIBE, PUBLISH, AND NOTIFY network, a network that supports OPTIONS way of capability exchange and a hybrid network.

In an embodiment, the MO <NUM> supports the SUBSCRIBE, PUBLISH, AND NOTIFY way of dedicated capability discovery procedure and the MT <NUM> supports OPTIONS way of dedicated capability discovery procedure and vice versa, in hybrid networks.

Although the <FIG> shows the hardware components of the MO <NUM> but it is to be understood that other embodiments are not limited thereon. In an embodiment, the MO <NUM> may include less or more number of components. Further, the labels or names of the components are used only for illustrative purpose and does not limit the scope of the invention. One or more components can be combined together to perform same or substantially similar function for identifying the In-Call capability features without dedicated capability discovery procedure.

<FIG> is a block diagram of the MT <NUM> for identifying the In-Call capability features without dedicated capability discovery procedure, according to an embodiment of the disclosure.

Examples for the MT <NUM> are, but not limited to a smart phone, a tablet computer, a personal computer, a personal digital assistance (PDA), an Internet of Things or the like. In an embodiment, the MT <NUM> may include, but not limited to a processor <NUM>, a memory <NUM> and a communicator <NUM>. In an embodiment, the processor <NUM> may include an In-Call capability message indicator <NUM>.

In an embodiment, the processor <NUM> may be configured to receive the call request message from the MO <NUM>. The In-Call capability message indicator <NUM> may receive the call request message from the MO <NUM>. The processor <NUM> may be configured to determine whether the MT <NUM> is a VOLTE device or a non-VOLTE device.

In an embodiment, determining whether the MT is the VOLTE device or the non-VOLTE device may include determining whether the In-Call capability features of the MO <NUM> is indicated in the contact header of the call request message. That is, information regarding In-Call capability features of the MO may be included in the contact header of the call request message.

Further, determining whether the MT is the VOLTE device or the non-VOLTE device may include determining whether the In-Call capability features of the MO <NUM> is indicated in the SIP private extension header of the call request message, in response to determining that the In-Call capability features of the MO is not indicated in the contact header of the call request message. That is, information regarding In-Call capability features of the MO may be included in the SIP private extension header of the call request message.

In an embodiment, the processor <NUM> may determines whether the MT <NUM> is the VOLTE device or non-VOLTE device. The In-Call capability message indicator <NUM> may determine whether the MT <NUM> is the VOLTE device or the non-VOLTE device.

In an embodiment, the processor <NUM> may be configured to send the call response message including the In-Call capability features of the MT <NUM> to the MO <NUM>, in response to determining that the MT <NUM> is the VOLTE device. In an embodiment, the In-Call capability message indicator <NUM> may send the call response message to the MO <NUM>, in response to determining that the MT <NUM> is the VOLTE device.

In an embodiment, the processor <NUM> may be configured to follow a legacy capability exchange including the In-Call capability features, in response to determining that the MT <NUM> is the non-VOLTE device. That is, the processor <NUM> may perform a legacy capability exchange for exchanging the information regarding In-Call capability features, when the MT is a non-VOLTE device.

In an embodiment, The In-Call capability message indicator <NUM> may follow the legacy capability exchange including the In-Call capability features, in response to determining that the MT <NUM> is the non-VOLTE device.

In an embodiment, the MT <NUM> may refer the contact header to know whether the MO <NUM> supports the In-Call capability features. If the In-Call capability features are not present in the contact header then the MT <NUM> may check the SIP private extension header. In an embodiment, when the MT <NUM> is the VOLTE device and does not support In-Call capability features, then the MT <NUM> may mark the SIP private extension header with value "none" and may send to the MO <NUM> for avoiding falling back to legacy mode.

In an embodiment, the processor <NUM> may be configured to execute instructions stored in the memory <NUM>. The memory <NUM> may include non-volatile storage elements. Examples of such non-volatile storage elements may include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of an Electrically Programmable Memory(EPROM) or an Electrically Erasable and Programmable Memory(EEPROM).

In an embodiment, the memory <NUM> can be configured to store larger amounts of information than the memory <NUM>. In For example, a non-transitory storage medium may store data that can, over time, change (e.g., in Random Access Memory (RAM) or cache) , but not limited to thereon.

The communicator <NUM> may be configured to communicate internally between hardware components in the MT <NUM>. Further, the communicator <NUM> may be configured to communicate the MT <NUM> to the MO <NUM>.

Although the <FIG> shows the hardware components of the MT <NUM> but it is to be understood that other embodiments are not limited thereon. In an embodiment, the MT <NUM> may include less or more number of components. Further, the labels or names of the components are used only for illustrative purpose and does not limit the scope of the invention. One or more components can be combined together to perform same or substantially similar function for identifying the In-Call capability features without dedicated capability discovery procedure.

<FIG> is a flow diagram <NUM> illustrating a method for identifying the In-Call capability features without dedicated capability discovery procedure by the MO <NUM>, according to an embodiment of the disclosure.

In operation <NUM>, the method may include sending the call request message to the MT <NUM>, wherein the call request message may include the In-Call capability features of the MO <NUM>. In an embodiment, the method may allow the In-Call capability message indicator <NUM> to send the call request message to the MT <NUM>, wherein the call request message may include the In-Call capability features of the MO <NUM>.

In operation <NUM>, the method may include receiving the call response message from the MT <NUM>, wherein the call response message may include the In-Call capability features of the MT <NUM>. In an embodiment, the method may allow the In-Call capability message indicator <NUM> to receive the call response message from the MT <NUM>, where the call response message may include the In-Call capability features of the MT <NUM>.

In operation <NUM>, the method may include performing the In-Call capability negotiation with the MT <NUM>. In an embodiment, the method may allow the In-Call capability negotiator <NUM> to perform the In-Call capability negotiation with the MT <NUM>.

The various actions, acts, blocks, steps, or the like in the flow diagram <NUM> may be performed in the order presented, in a different order or simultaneously. Further, in some embodiments, some of the actions, acts, blocks, steps, or the like listed in <FIG> may be omitted, added, modified, skipped, or the like without departing from the scope of the invention.

<FIG> is a flow diagram <NUM> illustrating a method for identifying the In-Call capability features without dedicated capability discovery procedure by the MT <NUM>, according to an embodiment of the disclosure.

In operation <NUM>, the method may include receiving the call request message from the MO <NUM>, wherein the call request message may include the In-Call capability features of the MO <NUM>. In an embodiment, the method may allow the In-Call capability message indicator <NUM> to receive the call request message from the MO <NUM>, where the call request message may include the In-Call capability features of the MO <NUM>.

In operation <NUM>, the method may include determining whether the MT <NUM> is one of the VOLTE device and the non-VOLTE device. In an embodiment, the method may allow the In-Call capability message indicator <NUM> to determine whether the MT <NUM> is one of the VOLTE device and the non-VOLTE device.

In operation <NUM>, the method may include sending the call response message including the In-Call capability features of the MT <NUM> to the MO <NUM>, in response to determining that the MT <NUM> is the VOLTE device. In an embodiment, the method may allow the In-Call capability message indicator <NUM> to send the call response message including the In-Call capability features of the MT <NUM> to the MO <NUM>, in response to determining that the MT <NUM> is the VOLTE device.

In operation <NUM>, the method may include following the legacy capability exchange including the In-Call capability features, in response to determining that the MT <NUM> is the non-VOLTE device. In an embodiment, the method may allow the In-Call capability message indicator <NUM> to follow the legacy capability exchange including the In-Call capability features, in response to determining that the MT <NUM> is the non-VOLTE device.

<FIG> is a sequential diagram illustrating signalling of the SIP messages between the MO <NUM> and the MT <NUM> to identify the In-Call capability features without dedicated capability discovery procedure, according to an embodiment of the disclosure.

In operation <NUM>, the MO <NUM> may send the INVITE message to the MT <NUM> for connecting to the MT <NUM> and indicating the In-Call capability features of the MO <NUM>. The contact header and the SIP private extension header of the INVITE message may include the In-Call capability features.

In operation <NUM>, the MT <NUM> may send the <NUM> OK message to the MO <NUM> for acknowledging the received INVITE message and indicating the In-Call capability features of the MT <NUM>. The contact header and the SIP private extension header of the <NUM> OK message may include the In-Call capability features of the MT <NUM>.

In operation <NUM>, the MO may to send acknowledge to the MT, in response to receiving the <NUM> OK message.

<FIG> is a sequential diagram illustrating signalling of the SIP messages between the MO <NUM> and MT <NUM> for holding a call during a call session, according to an embodiment of the disclosure.

Consider, the MO <NUM> is connected to the MT <NUM> for a call session. The MO <NUM> may remove the In-Call capability features in the contact header and the SIP private extension header of the INVITE message and may mark as 'none'.

In operation <NUM>, the MO <NUM> may send the INVITE message to the MT <NUM> for holding the call. In response to receiving the INVITE message, the MT <NUM> may remove the In-Call capability features in the contact header and the SIP private extension header of the <NUM> OK message and may mark as 'none'.

In operation <NUM>, the MT <NUM> may send the <NUM> OK message to the MO <NUM>, indicating that the MT <NUM> is ready to hold the call.

In operation <NUM>, the MO <NUM> may to send acknowledge to the MT <NUM> and holds the call, in response to receiving the <NUM> OK message. Similarly, the call on hold can be resume by signalling between the MO <NUM> and MT <NUM> based on the proposed method.

The elements shown in <FIG> and <FIG> can be at least one of a hardware device, or a combination of hardware device and software module.

Claim 1:
A method performed by a mobile originated, MO, device (<NUM>) in a wireless communication system, the method comprising:
transmitting (<NUM>, <NUM>), to a mobile terminated, MT, device (<NUM>), a session initiation protocol, SIP, INVITE request message including information regarding in-call capability features of the MO device (<NUM>),
wherein the information regarding in-call capability features of the MO device (<NUM>) is included in a contact header of the SIP INVITE request message in a single registration,
wherein the information regarding in-call capability features of the MO device (<NUM>) is included in a SIP private extension header of the SIP INVITE request message in a dual registration,
wherein in the single registration, a Voice Over Long Term Evolution, VOLTE, and a Rich Communication Service, RCS, are registered on a single Packet Data Network, PDN, for a same International Mobile Subscriber Identity, IMSI, or Mobile Subscriber Integrated Services Digital Network, MSISDN, and
wherein in the dual registration, the VOLTE and the RCS are registered on a different PDN for the same IMSI or MSISDN;
in response to the SIP INVITE request message, receiving (<NUM>, <NUM>), from the MT device (<NUM>), a response message including information regarding in-call capability features of the MT device (<NUM>),
wherein the reception of the response message including the information regarding in-call capability features of the MT device (<NUM>) is performed based on a determination whether the MT device (<NUM>) is the VOLTE device or not,
wherein the determination whether the MT device (<NUM>) is the VOLTE device or not comprises a determination whether the information regarding in-call capability features of the MO device (<NUM>) is indicated in the contact header or the SIP private extension header of the SIP INVITE request message; and
performing (<NUM>) in-call capability negotiation with the MT device (<NUM>).