System and method for managing synchronization in a conference call

Abstract

A method for managing synchronization in a conference call is disclosed. The method includes establishing, by a first user equipment (UE), a call session associated with the conference call with one or more second UEs. Further, the method includes determining, by the first UE, a latency value associated with the call session for each of the one or more second UEs. The method also includes determining, by the first UE, a user experience quotient for the call session associated with each of the one or more second UEs. Furthermore, the method includes modifying, by the first UE, a first size of one or more data packets to a second size for each of the one or more second UEs based on a corresponding user experience quotient of the call session associated with the one or more second UEs.

Description

SYSTEM AND METHOD FOR MANAGING SYNCHRONIZATION IN A CONFERENCE CALL

[0001] The disclosure generally relates to communication technology, for example, the disclosure relates to a system and a method for managing synchronization in a conference call.

[0002] In the fast-paced world of technological advancements, video calls have emerged as a cornerstone of modern communication, reshaping the way individuals and businesses connect across the globe. The acceleration in video call service usage is largely attributed to new situations, such as remote work and emotional connection with families during and post pandemic. To address such requirement, some over-the-top (OTT) solutions exist to enable video calling. However, such existing OTT solutions lack the user experience (UX) and seamless interworking between different devices, such as mobile and television for a better viewing experience.

[0003] Further, there are multiple existing synchronization (sync) solutions available for multi-party video calls for alignment of audio and video streams between participants. However, there are multiple challenges associated with the existing synch solutions. For example, in existing sync solutions, sender centric approaches are disclosed where all receivers sync video of the sender, and hence content can be omitted at the receiver. This results in a poor viewing experience at the receiver where a portion of content is omitted. Furthermore, the sync server knows the play time / content availability time at receivers. Currently, the sync server does not integrate with a content server to control the transmission properties (how much data to transmit) of the content server. This results in high buffer time at receivers during a bad network. Also, in a video conference, the communication server relays the video and speech data type. The content server relays the content data type. When the sender is sharing the content and talking about the content, both these data types (video / speech and content) should be synchronized. Currently, this is not supported in the existing sync solutions.

[0004] Figure 1a illustrates a block diagram 100 showing problems with existing sync solutions, according to a related art. In the existing sync solutions, content, communication, and synchronization occur independently. Further, as shown, a content server is for the content storage, a communication server is for the video conference, the sync server is configured to maintain synchronization of the content, the sender is a device that shares the content, and a receiver is a device which receives the content. In the existing sync solutions, the content transmission doesn't control or adapt based on synchronization. Also, the content latency and the video conference latency are not synchronized.

[0005] Furthermore, the existing sync solutions provide sender centric sync to the user and fail to provide a continuous sync. Further, the video sync occurs only with user actions, such as play / pause. In network fluctuation scenarios, the play position is continuously different for two users. Also, in the existing sync solutions, there is no feature for local file sharing together. The only option provided in the existing sync solutions is screen share which has serious limitations, such as screen sharing is not interactive (other participants can't control video). Further, original quality and aspect ratio of the video are not preserved while sharing the screen. As a result, the existing sync solutions provide a poor viewing experience and increased latency. Furthermore, in the existing sync solutions, redundant content is streamed with a screen share option that is not intended for the receiver, such as notifications, toolbar, and the like. Also, the sender device cannot be used for other tasks while screen sharing is being used. Also, the existing sync solutions do not provide an option to apply custom sync mechanisms.

[0006] Further, to provide an immersive watch together experience to users, a perfect sync is required in playing the content at all user's end. For example, the users want to share videos from their devices with their friends / family. However, the existing sync solutions face issues related to content omission as they fail to provide synchronization with ongoing conferences. For example, if synchronization is performed based on a single user (mostly sender / broadcaster) without considering other user's play position, all other users omit playing content as they are behind broadcaster play position.

[0007] Furthermore, the content streaming and synchronization are independent in the existing solutions i.e. content transmission properties (ex: chunk size) are not adaptable based on synchronization experience. In varying network conditions of consumers, without adaptation, different users have different amounts of data, as content downloading and playing happens in parallel thereby different play positions (some consumers start playing, some consumers yet to download data).

[0008] Figure 1b illustrates a block diagram 102 showing a problem of play delay with existing sync solutions, according to a related art. As shown, the receiver is in good condition and initial transmission size is 10 megabyte (MB) (max size). Now, all receivers have 10MB (say 10 sec) content to play, all users started playing content part-1 10MB (10 sec). Further, one of the users is in mobility to low bandwidth. Accordingly, to download content part-2 of 10MB size, the user may take 12 secs. Remaining consumers may take less time. Thus, after playing part-1 of 10MB (10 sec), part-2 is available only after 2 seconds from playing complete chunk-1. Accordingly, there is a play delay of 2 seconds as no content is available.

[0009] Further, the existing sync solutions fail to consider ongoing video conference latency. The synchronization between video conferencing and content viewing is necessary. Video conference is real time and content streaming is near real time but in share together scenario both need to be synchronized, then only experience is considered good. For example, when users are watching a movie together in a video conference and the user claps in between a scene, the existing sync solutions fail to sync the clap with the scene for other users. Furthermore, the existing sync solutions don't work for peer to peer (P2P) mode (due to the Sync server being enforced). Thus, the existing sync solutions are costly and have minimal latency.

[0010] The above information is presented as background information only to assist with an understanding of the disclosure. No determination has been made, and no assertion is made, as to whether any of the above might be applicable as prior art with regard to the disclosure.

[0011] In an example embodiment, a method for managing synchronization in a conference call is disclosed. The method includes establishing, by a first user equipment (UE), a call session associated with the conference call with one or more second UEs. Further, the method includes determining, by the first UE, a latency value associated with the call session for each of the one or more second UEs. The method also includes determining, by the first UE, a user experience quotient for the call session associated with each of the one or more second UEs. Furthermore, the method includes modifying, by the first UE, a first size of one or more data packets to a second size for each of the one or more second UEs based on a corresponding user experience quotient of the call session associated with the one or more second UEs.

[0012] In an example embodiment, a first user equipment for managing synchronization in a conference call is disclosed. The first UE memory storing instructions and one or more processors, wherein the instructions, when executed by the one or more processors individually or collectively, cause the first UE to: establish a call session associated with the conference call with one or more second UEs; determine a latency value associated with the call session for each of the one or more second UEs; determine a user experience quotient for the call session associated with each of the one or more second UEs; and modify a first size of one or more data packets to a second size for each of the one or more second UEs based on a corresponding user experience quotient of the call session associated with the one or more second UEs.

[0013] In an example embodiment, non-transitory computer-readable storage medium storing one or more programs comprising instructions is disclosed. The instructions, when executed by at least one processor of a first user equipment (UE) individually or collectively, cause the first UE to: establish a call session associated with the conference call with one or more second UEs; determine a latency value associated with the call session for each of the one or more second UEs; determine a user experience quotient for the call session associated with each of the one or more second UEs; and modify a first size of one or more data packets to a second size for each of the one or more second UEs (203) based on a corresponding user experience quotient of the call session associated with the one or more second UEs.

[0014] To further clarify the advantages and features of the disclosure, a more particular description of the disclosure will be rendered by reference to specific embodiments thereof, which are illustrated in the appended drawings. It is appreciated that these drawings depict only typical embodiments of the disclosure and are therefore not to be considered limiting of its scope. The disclosure will be described and explained with additional specificity and detail with the accompanying drawings.

[0015] These and other features, aspects, and advantages of the disclosure will become better understood when the following detailed description is read with reference to the accompanying drawings in which like characters represent like parts throughout the drawings, wherein:

[0016] Figure 1a illustrates a block diagram showing problems with existing sync solutions, according to a related art;

[0017] Figure 1b illustrates a block diagram showing a problem of play delay with existing sync solutions, according to a related art;

[0018] Figure 2 illustrates a block diagram of a system for managing synchronization in a conference call, according to an embodiment of the disclosure;

[0019] Figure 3 illustrates a block diagram of a plurality of modules of the system at a sender user equipment (UE) for managing synchronization in the conference call, according to an embodiment of the disclosure;

[0020] Figure 4 illustrates a block diagram for handling distributed sync session and play session at a sender UE and one or more receivers UE, according to an embodiment of the disclosure;

[0021] Figure 5 illustrates a schematic representation of play session state transition based on sync messages, according to an embodiment of the disclosure;

[0022] Figure 6 illustrates a sequence diagram depicting an operation of the system for managing synchronization in the conference call, according to an embodiment of the disclosure;

[0023] Figure 7a and Figure 7b illustrates a sequence diagram depicting an operation of the system for managing synchronization in the conference call, according to another embodiment of the disclosure;

[0024] Figure 8 illustrates a flowchart depicting an operation of the system at the sender UE for managing synchronization in the conference call, according to an embodiment of the disclosure;

[0025] Figure 9 illustrates a flowchart depicting an operation of the system at a receiver UE for managing synchronization in the conference call, according to an embodiment of the disclosure;

[0026] Figure 10 illustrates a block diagram showing a use-case scenario of the system for managing synchronization in the conference call, according to an embodiment of the disclosure;

[0027] Figure 11 illustrates a flow chart showing a use-case scenario of the system for managing synchronization in the conference call, according to an embodiment of the disclosure;

[0028] Figure 12 illustrates a pictorial depiction showing a use-case scenario of the system for managing synchronization in the conference call, according to an embodiment of the disclosure; and

[0029] Figure 13 illustrates an exemplary process flow depicting a method for managing synchronization in the conference call, according to an embodiment of the disclosure.

[0030] Further, skilled artisans will appreciate those elements in the drawings are illustrated for simplicity and may not have necessarily been drawn to scale. For example, the flow charts illustrate the method in terms of the most prominent steps / operations involved to help to improve understanding of aspects of the disclosure. Furthermore, in terms of the construction of the device, one or more components of the device may have been represented in the drawings by conventional symbols, and the drawings may show only those specific details that are pertinent to understanding the embodiments of the disclosure so as not to obscure the drawings with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein.

[0031] It may be advantageous to set forth definitions of certain words and phrases used throughout this patent document. The term "couple" and its derivatives refer to any direct or indirect communication between two or more elements, whether or not those elements are in physical contact with one another. The terms "transmit," "receive," and "communicate," as well as derivatives thereof, encompass both direct and indirect communication. The terms "include" and "comprise," as well as derivatives thereof, mean inclusion without limitation. The term "or" is inclusive, meaning and / or. The phrase "associated with," as well as derivatives thereof, means to include, be included within, interconnect with, contain, be contained within, connect to or with, couple to or with, be communicable with, cooperate with, interleave, juxtapose, be proximate to, be bound to or with, have, have a property of, have a relationship to or with, or the like. The term "controller" means any device, system, or part thereof that controls at least one operation. Such a controller may be implemented in hardware or a combination of hardware and software and / or firmware. The functionality associated with any particular controller may be centralized or distributed, whether locally or remotely. The phrase "at least one of," when used with a list of items, means that different combinations of one or more of the listed items may be used, and only one item in the list may be needed. For example, "at least one of: A, B, and C" includes any of the following combinations: A, B, C, A and B, A and C, B and C, and A and B and C.

[0032] Moreover, various functions described below can be implemented or supported by one or more computer programs, each of which is formed from computer readable program code and embodied in a computer readable medium. The terms "application" and "program" refer to one or more computer programs, software components, sets of instructions, procedures, functions, objects, classes, instances, related data, or a portion thereof adapted for implementation in a suitable computer readable program code. The phrase "computer readable program code" includes any type of computer code, including source code, object code, and executable code. The phrase "computer readable medium" includes any type of medium capable of being accessed by a computer, such as read only memory (ROM), random access memory (RAM), a hard disk drive, a compact disc (CD), a digital video disc (DVD), or any other type of memory. A "non-transitory" computer readable medium excludes wired, wireless, optical, or other communication links that transport transitory electrical or other signals. A non-transitory computer readable medium includes media where data can be permanently stored and media where data can be stored and later overwritten, such as a rewritable optical disc or an erasable memory device.

[0033] Definitions for other certain words and phrases are provided throughout this patent document. Those of ordinary skill in the art should understand that in many, if not most instances, such definitions apply to prior as well as future uses of such defined words and phrases.

[0034] Figure 2 illustrates a block diagram of a system 200 for managing synchronization in a conference call, according to an embodiment of the present disclosure. In an embodiment of the disclosure, the system 200 is implemented in a sender user equipment (UE) 202 and one or more receiver UEs 203. The sender UE 202 is communicatively coupled to the one or more receiver UEs 203 for attending the conference call. In an embodiment of the disclosure, the sender UE 202 is the user equipment (device) from which audio and / or video data is being transmitted to the conference call. Further, the one or more receiver UEs 203 are user equipment (devices) that are receiving the audio and / or video data transmitted by the sender UE 202 in the conference call. For example, the sender UE 202 and the one or more received UEs may be, but is not limited to, a smartphone, tablet, laptop, smartwatch, and the like. For the sake of brevity, the system 200 is explained with reference to the sender UE 202.

[0035] The system 200 may include one or more processors / controllers (e.g., including processing circuitry) 204, an Input / Output (I / O) interface 206, a plurality of modules 208, and a memory 210.

[0036] In an exemplary embodiment, one or more processors / controllers 204 may be operatively coupled to each of the respective I / O interface 206, the plurality of modules 208, and the memory 210. In one embodiment, one or more processors / controllers 204 may include at least one data processor for executing processes in a Virtual Storage Area Network. The one or more processors / controllers 204 may include specialized processing units such as integrated system (bus) controllers, memory management control units, floating point units, graphics processing units, digital signal processing units, etc. In one embodiment, the one or more processors / controllers 204 may include a central processing unit (CPU), a graphics processing unit (GPU), or both. The one or more processors / controllers 204 may be one or more general processors, digital signal processors, application-specific integrated circuits, field-programmable gate arrays, servers, networks, digital circuits, analog circuits, combinations thereof, or other now known or developed devices for analyzing and processing data. The one or more processors / controllers 204 may execute a software program, such as code generated manually (i.e., programmed) to perform the desired operation. In an embodiment of the disclosure, the processors / controllers 204 may be a general-purpose processor, such as the CPU, an application processor (AP), or the like, a graphics-only processing unit such as the GPU, a visual processing unit (VPU), and / or an artificial intelligence (AI)-dedicated processor, such as a neural processing Unit (NPU). Furthermore, the processor(s) 202 may include various processing circuitry and / or multiple processors. For example, as used herein, including the claims, the term "processor" may include various processing circuitry, including at least one processor, wherein one or more of at least one processor, individually and / or collectively in a distributed manner, may be configured to perform various functions described herein. As used herein, when "a processor", "at least one processor", and "one or more processors" are described as being configured to perform numerous functions, these terms cover situations, for example and without limitation, in which one processor performs some of recited functions and another processor(s) performs other of recited functions, and also situations in which a single processor may perform all recited functions. Additionally, the at least one processor may include a combination of processors performing various of the recited / disclosed functions, e.g., in a distributed manner. At least one processor may execute program instructions to achieve or perform various functions.

[0037] Further, the one or more processors / controllers 204 control the processing of input data in accordance with a specified operating rule or machine learning (ML) model stored in the non-volatile memory and the volatile memory. The specified operating rule or the ML model is provided through training or learning.

[0038] Here, being provided through learning means that, by applying a learning technique to a plurality of learning data, a specified operating rule or the ML model of a desired characteristic is made. The learning may be performed in the sender UE 202 itself in which ML according to an embodiment is performed, and / or may be implemented through a separate server / system.

[0039] The one or more processors / controllers 204 may be disposed in communication with one or more input / output (I / O) devices via the respective I / O interface 206. The I / O interface 206 may employ communication code-division multiple access (CDMA), high-speed packet access (HSPA+), global system for mobile communications (GSM), long-term evolution (LTE), WiMax, or the like, etc.

[0040] The one or more processors / controllers 204 may be disposed of in communication with a communication network via a network interface. In an embodiment, the network interface may be the I / O interface 206. The network interface may connect to the communication network to enable the connection of the sender UE 202 with the one or more receiver UEs 203. The network interface may employ connection protocols including, without limitation, direct connect, ethernet (e.g., twisted pair 10 / 100 / 1000 Base T), transmission control protocol / internet protocol (TCP / IP), token ring, IEEE 802.11a / b / g / n / x, etc. The communication network may include, without limitation, a direct interconnection, local area network (LAN), wide area network (WAN), wireless network (e.g., using wireless application protocol), the internet, and the like.

[0041] In some embodiments, the memory 210 may be communicatively coupled to the one or more processors / controllers 204. The memory 210 may be configured to store data, and instructions executable by the one or more processors / controllers 204. The memory 210 may include but is not limited to, a non-transitory computer-readable storage media, such as various types of volatile and non-volatile storage media including, but not limited to, random access memory, read-only memory, programmable read-only memory, electrically programmable read-only memory, electrically erasable read-only memory, flash memory, magnetic tape or disk, optical media and the like. In one example, the memory 210 may include a cache or random-access memory for the one or more processors / controllers 204. In alternative examples, the memory 210 may be a part of the one or more processors / controllers 204, such as a cache memory of a processor, the system memory, or other memory. In some embodiments, the memory 210 may be an external storage device or database for storing data. The memory 210 may be operable to store instructions executable by the one or more processors / controllers 204. The functions, acts, or tasks illustrated in the figures or described may be performed by the programmed processor / controller for executing the instructions stored in the memory 210. The functions, acts, or tasks are independent of the particular type of instruction set, storage media, processor, or processing strategy and may be performed by software, hardware, integrated circuits, firmware, micro-code, and the like, operating alone or in combination. Likewise, processing strategies may include multiprocessing, multitasking, parallel processing, and the like.

[0042] In some embodiments, the plurality of module 208 may be included within the memory 210. The memory 210 may further include a system database 212 to store data. The plurality of modules 208 may include a set of instructions that may be executed to cause the one or more processors 102 of the system 200 to perform any one or more of the methods / processes disclosed herein. The plurality of modules 208 may be configured to perform the steps / operations of the disclosure using the data stored in the system database 212 for managing synchronization in the conference call, as discussed herein. In an embodiment, each of the plurality of modules 208 may be a hardware unit that may be outside the memory 210. Further, the memory 210 may include an operating system 214 for performing one or more tasks of the system 200, as performed by a generic operating system 214 in the communications domain. In one embodiment, the system database 212 may be configured to store the information as required by the plurality of modules 208 and the one or more processors / controllers 204 for managing synchronization in the conference call.

[0043] In an embodiment of the disclosure, at least one of the plurality of modules 208 may be implemented through the ML model. A function associated with the ML may be performed through the non-volatile memory, the volatile memory, and the one or more processors 204.

[0044] In an embodiment, the I / O interface 206 may enable input and output to and from the system 200 using suitable devices such as, but not limited to, a display, a keyboard, a mouse, a touch screen, a microphone, a speaker, and so forth.

[0045] Further, the disclosure also contemplates a computer-readable medium that includes instructions or receives and executes instructions responsive to a propagated signal. Further, the instructions may be transmitted or received over the network via a communication port or interface or using a bus. The communication port or interface may be a part of the one or more processors / controllers 204 or may be a separate component. The communication port may be created in software or may be a physical connection in hardware. The communication port may be configured to connect with a network, external media, the display, or any other components in the device 202, or combinations thereof. The connection with the network may be a physical connection, such as a wired Ethernet connection, or may be established wirelessly. Likewise, the additional connections with other components of the device 202 may be physical or may be established wirelessly. The network may alternatively be directly connected to the bus. For the sake of brevity, the architecture and standard operations of the operating system 214, the memory 210, the system database 212, the one or more processors / controllers 204, and the I / O interface 206 are not discussed in detail.

[0046] Figure 3 illustrates a block diagram of a plurality of modules of the system 200 at a sender UE 202 for managing synchronization in a conference call, according to an embodiment of the disclosure. In an embodiment of the disclosure, the plurality of modules 208 may include but is not limited to, an establishing module 302, a calculating module 304, a determining module 306, a modifying module 308, a transmitting module 310, and a removing module 312. The plurality of modules 208 may be implemented by way of suitable hardware and / or software applications.

[0047] In an embodiment of the disclosure, the establishing module 302 may be configured to establish, by the sender UE 202, a call session associated with the conference call with the one or more receiver UEs 203.

[0048] Further, the calculating module 304 may be configured to determine, by the sender UE 202, a latency value associated with the established call session for each of the one or more receivers. In an embodiment of the disclosure, the latency value refers to the amount of delay between the initiation of a communication event and the time when it is received or perceived by the one or more receiver UEs 203. In determining the latency value, the calculating module 304 may be configured to transmit, by the sender UE 202, the one or more data packets of the first size to the one or more receiver UEs 203. Further, the calculating module 304 may be configured to receive, by the sender UE 202, a transmission report from the one or more receivers, a conference report from a server, or a combination thereof upon transmitting the one or more data packets of the first size to the one or more receiver UEs 203. In an embodiment of the disclosure, the transmission report is a control message containing values, such as round-trip time. The transmission report is used to determine the channel latency between the sender UE 202 and the one or more receiver UEs 203. Further, the transmission report determines the current state of media play at the one or more receiver UE. In an embodiment of the disclosure, the transmission report is per receiver. Furthermore, the conference report is a control message containing average real-time video conference latency determined by a conference server for the entire video conference session. The transmission report represents the whole video conference session. The calculating module 304 may be configured to determine, by the sender UE 202, the latency value for each of the one or more receiver UEs 203 based on the received at least one of the transmission report or the conference report.

[0049] Furthermore, the determining module 306 may be configured to determine, by the sender UE 202, a user experience quotient for the call session associated with each of the one or more receivers. In an embodiment of the disclosure, the user experience quotient corresponds to a measure of the quality of user experience during the conference call. In determining the user experience quotient, the determining module 306 may be configured to determine the user experience quotient based on play time, buffer time, and number of transitions between session states of the one or more receiver UEs 203. In an embodiment of the disclosure, the user experience quotient is a value derived by the sender UE 202 for the session which represents smoothness of the play collectively for all users. The user experience quotient varies between 0 and 1, 1 is the best experience and 0 is bad experience. In an embodiment of the disclosure, a threshold value is between 0 and 1. For example, the threshold value may be 0.8, below 0.8 considered as poor viewing experience.

[0050] The details on determining the user experience quotient have been elaborated in subsequent paragraphs at least with reference to Figure 5.

[0051] Further, the modifying module 308 may be configured to modify, by the sender UE 202, a first size of the data packets to a second size for each of the one or more receivers based on a corresponding user experience quotient of the call session associated with the one or more receivers.

[0052] Furthermore, the transmitting module 310 may be configured to transmit, by the sender UE 202, state session synchronization messages and data packets of a first size to the one or more receiver UEs 203 based on the determined latency value. In an embodiment of the disclosure, the data packets are associated with a media to be played on each of the sender UE 202 and the one or more receiver UEs 203. In transmitting the state session synchronization messages, the transmitting module 310 may be configured to determine, by the sender UE 202, a media state of the media session for the one or more receiver UEs 203 based on the latency value. In an embodiment of the disclosure, the media state is to play, pause, or continue the media session on the one or more receiver UEs 203. Further, the transmitting module 310 may be configured to transmit, by the sender UE 202, the state session synchronization messages associated with the determined media state to the one or more receiver UEs 203 for play, pause, or continue the media session on the one or more receiver UEs 203 In an embodiment of the disclosure, session state synchronization message are control messages (such as play, continue, buffer, and the like) that make sure play state is uniform at all the users in the session.

[0053] The details on managing the media session have been elaborated in subsequent paragraphs at least with reference to Figures 4 and 5.

[0054] Further, the removing module 312 may be configured to determine that the user experience quotient of the call session associated with a receiver UE from the one or more receiver UEs 203 is below a specified threshold. The removing module 312 may be configured to remove the receiver UE from the call session upon determining that the user experience quotient of the call session associated with the receiver UE is below the specified threshold.

[0055] Figure 4 illustrates a block diagram depicting an operation of the system 200 for performing the thermal-based frame interpolation, according to an embodiment of the disclosure. As explained with reference to Figures 2 and 3, the system 200 manages synchronization in the conference call.

[0056] As depicted, the sender UE 202 (broadcaster i.e., sender of content) is communicatively coupled with a first receiver UE 402 and a second receiver UE 404 (i.e., receiver for content) via a relay server 406. Further, the sender UE 202 includes a play session unit 408, a content session unit 410, and a sync session unit 412. The relay server 406 includes a latency manager 414, a content relay 416, and a sync relay 418. In an embodiment of the disclosure, the relay server 406 relays messages when P2P is not possible. Further, the latency manager 414 checks latency based on real-time transport control protocol (RTCP) reports between the sender UE 202 and the first receiver UE 402, and the second receiver UE 404. In an embodiment of the disclosure, the content relay 416 is the process of relaying content (data, information, media, etc.) from the sender UE 202 to the first receiver UE 402 and the second receiver UE 404 through the relay server 406. Furthermore, the sync relay 418 performs synchronization of data between the sender UE 202, the first receiver UE 402, and the second receiver UE 404.

[0057] In an embodiment of the disclosure, each of the first receiver UE 402 and the second receiver UE 404 includes a sync session unit 420, 422, a play session unit 424, 426, and a content session unit 428, 430. The sync session units 412, 420, and 422 manage the sync session to generate sync messages based on reports (such as the RTCP report) from the content session and the conference session (external to this). At the receiver side (the first receiver UE 402, and the second receiver UE 404), the sync session units 420, and 422 process the incoming sync messages. The sync session unit 420, 422 of the receiver side 402, 404 communicates with the play session unit 424, 426 of the receiver side 402, 404 to indicate a buffer management queue for content play. Further, the sync session unit 420, 422 of the receiver side 402, 404 also derives transmission unit (chunk) size required for considering all receivers based on play position and content availability at the receiver side 420, 424.

[0058] Further, the play session unit 408, 424, and 426 manages the content buffer received in the content session and interact with a media player based on sync session buffer management indications. The play session units 408, 424, and 426 report content availability and player current position to the sync session units 412, 420, and 422. Furthermore, the content session unit 410, 428, and 430 manages the content transmission. The content session 410, 428, and 430 units adapts the transmission (chunk) unit size for a better play experience based on sync session feedback.

[0059] Figure 5 illustrates a schematic representation of play session state transition based on sync messages, according to an embodiment of the disclosure. As explained with reference to Figures 2 and 3, the system 200 manages synchronization in the conference call.

[0060] As shown, there are multiple transition states associated with the UEs involved in the conference call, such as an idle state 502, a playing state 504, and a buffering state 506. The idle state 502 is the content transmission start state where media player is initialized. Further, the playing state 504 is the state where all consumers view the content. The consumer is in the playing state 504 after data availability and sync session messages are in "play" or "continue" states. Further, all users buffer in in the buffering state 506 upon receiving "pause" message from the sync session. In an embodiment of the disclosure, the state transition happens for all consumers at the same time.

[0061] Initially, the playing state 504 for all receivers is idle (i.e. not playing any content). The sender's sync unit may send a "play" sync message to receivers and the state of all receivers and sender may transition to the playing state 504. Due to network problem at the one or more receiver UEs 203, the sender's sync unit may send "pause" sync message to the one or more receivers UE. As a result, the sender UE's and the one or more receiver UEs' 203 state may transition to buffering state 506. Also, the sender UE 202 may send "continue" sync message to the one or more receiver UEs 203 to retain their current states.

[0062] In an embodiment of the disclosure, the user experience quotation is determined for the call session associated with each of the one or more receivers. The user experience quotation is a function of continuous play, continuous buffer time, and buffering count. In an embodiment of the disclosure, the user experience quotient is a quotient derived from a number of times play is switched to buffer state (X) and how much the content is continuously playing (Y). In an embodiment of the disclosure, the network latency of terminals is the constant factor. Thus, the user experience quotient is based on trade-off. Furthermore, X and Y are inversely proportional. The system 200 is required to find accurate Y, such that X is minimal. The user experience quotient is determined using equation (1):

[0063] User Experience quotient = Play time / (Playtime + transition count *α + time in buffer state * β)…(1)

[0064] Here, playtime and buffer time play session in playing state and buffering state respectively. Further, transition count corresponds to how many times content play switches from play state to transition state. Furthermore, buffer α and β are penalties for transition to buffer state and time to stay in un-buffering states.

[0065] Further, the user's quality of experience is perceived based on continuous play time. In case of network fluctuation, the video may buffer while downloading the content. Thus, optimizing buffer and play time is necessary. The buffer time and the play time may be optimized by trading off buffer time, play time, and state transitions. Thus, the system 200 is required to handle these three aspects (buffer time, play time, and state transitions) in synchronization sessions as it cumulatively affects experience of all users (determined by the user experience quotient). The system 200 adapts chunk size to improve the quotient. When this quotient value for a particular receiver goes below a specified threshold (e.g. 0.6) the system 200 removes that receiver from the synchronized session, such that that it does not drastically hampers viewing experience for other receivers.

[0066] Furthermore, the user experience quotient ranges between 0 and 1, 1 indicates a good experience and 0 indicates a bad experience for consumer. In an embodiment of the disclosure, α and β are penalties given for state transitions from playing to buffering states and buffer time at consumer. For example, when whole playtime of content is 100sec, penalties α and β are 5 and 1 respectively. Case-1: Good Experience: no buffering at consumers. i.e. time in buffer state = 0 and transition count = 0. Based on equation (1), the user experience quotient is 1. Case-2: Optimal Experience: minimal buffer at user. Consider time in buffer state = 10 and transition count = 3, the user experience quotient is 0.8. Case-3: bad experience (<0.75 threshold): consider time in buffer state = 15 and transition count = 5, the user experience quotient is 0.71.

[0067] Figure 6 illustrates a sequence diagram depicting an operation of the system 200 for managing synchronization in the conference call, according to an embodiment of the disclosure. The system 200 for managing synchronization in the conference call is explained with reference to Figures 2 and 3.

[0068] Figure 6 illustrates the full signalling process. The sender (i.e., sender UE 202) and receivers (receiver 1 and receiver 2) join the video conference call, and the sender attempts to share a video to share together with all receivers. Further, at operation 602, the sync session is established. The content streaming along with sync session gets established with receivers. Further, the sync session unit, the play session unit, the content session unit gets initialized. The content is divided into transmission units (or chunks) by the sender. Furthermore, the receiver 1, and receiver 2 (also called a first receiver and a second receiver UE) may receive transmission units from the sender. Based on this, the receiver 1 and receiver 2 may generate transmission reports (including receiver timestamp and round-trip time). These individual reports from all receivers may be sent to sender. Further, the sender may generate content streaming latency values for each receiver separately.

[0069] Also, the sender may generate video conference latency based on RTCP reports received from the media server (used for maintaining video call session). Based on these two latencies, the sender may generate a cumulative latency for each receiver individually. In an embodiment of the disclosure, the content streaming latency is the latency of file transmission delay at each receiver i.e., delay of whole transmission unit (chunk) from sender to receiver receiving whole transmission unit (chunk). Further, the conference latency is the latency of sender / receiver with media (voice / video) server, as video conference is real time media. The conference latency is approximately same at all receivers. In case of relay being used between sender and receiver, the latency manager 414 is required at relay unit to determine latency between sender and relay or relay and receiver. In P2P mode and in direct communication between sender and receiver, there is no requirement of relay.

[0070] At operation 604, the sender may send "play" sync message along with cumulative latency value to each receiver (data availability at the receiver is understood based on reports) based on cumulative latency determined by the sender. Further, the send may receive acknowledgement for the play sync messages from the receivers. In an embodiment of the disclosure, content play happen at all receivers at the same time based on indicated latency value for each receiver.

[0071] At operation 606, the sync session unit of the sender may issue "transmission unit modification" (chunk size adaption) indication to the content session in the sender based on user experience quotation determined by the sender for improving play experience in network fluctuation scenario. As a result, the chunk size is adapted to improve the user experience. Also, if the user experience quotient is less than a specified threshold at a particular receiver the receiver may be opted out of the sync session.

[0072] Figure 7a and Figure 7b illustrates a sequence diagram depicting an operation of the system 200 for managing synchronization in the conference call, according to another embodiment of the disclosure. The system for managing synchronization in the conference call is explained with reference to Figure 2 and Figure 3.

[0073] At operation 702 (i.e., operations 702A and operation 702B), the system 200 establishes the conference session and content session. Specifically, at operation 702A, users (such as, friends and families) establish video conference by creating a meeting room and sharing an invite link with all the users. Further, each user joins using the meeting link. Further, at operation 702B, the user who wants to discuss a video in his local file storage uses the system 200 and opens a file from local storage, and shares with all receivers in the conference. As a result, a distributed sync session gets established along with the content session and the play session with all the users (sender / broadcaster and receivers) of conference. This sync session is key to having a seamless share together experience by keeping all receivers content play session precisely at the same location so that their emotions in the video conference match to the video being watched. Also, this sync session takes care of matching video conference latency to the content view latency.

[0074] At operation 704, the content streaming starts with the initial transmission size (ex: 10Mb). In an embodiment of the disclosure, the transmission size corresponds to the buffer unit which is treated as a single unit for playing. Based on this content file is divided into N units. The transmission unit (or chunk) C1 is streamed to other participants. (may be with P2P or with a relay server). Supporting P2P in the system 200 is crucial to achieve low latency and low deployment cost to achieve synchronization.

[0075] At operation 706, the sender receives transmission report from receiver 2, which contains downloaded content information, such as bytes, receiver timestamp, and round trip time based on which the sender determines latency. For example, end to end latency between the sender and receiver-2 is α1.

[0076] Similarly, at operation 708, a transmission report is received from receiver 1. For example, latency with receiver-1 is α2.

[0077] Meanwhile, at operation 710, the sync session unit at the sender may receive video conference latency from the media server. Consider conference latency is measured as ∂1 at this moment. In an embodiment of the disclosure, the video conference latency is also included in synchronization of content viewing which greatly enhances the customer experience as the emotions displayed in the video are matched to the content that is being watched.

[0078] At operation 712, the sync session unit at the sender sends a sync message (PLAY) to other receivers. With the individual latencies received by receivers, the play session state transition occurs. Similarly, the sender play session transition occurs. Here the synchronization achieved by having sync session technique ensures that this state transition occurs at the same time at all consumers including the sender. This is achieved with reports of content availability at all receivers before generating a sync message.

[0079] At operation 714, the sync session invokes a play session with transmission data C1.

[0080] Meanwhile, at operation 716, the content session starts transmitting transmission unit C2.

[0081] At operation 718, the receivers started video playing together as per the latency provided to the clients (which is computed based on conference latency, content availability, and streaming latency).

[0082] At operation 720, the transmission data C2 report is received from receiver-2. For example, latency with receiver-2 is α11.

[0083] At operation 722, the transmission data C2 report is received from receiver-1. For example, latency with receiver-1 is α21.

[0084] At operation 724, the transmission report received with data bytes indicates content availability (the availability of full transmission unit (complete chunk)) at the receivers). Based on the content availability, all receivers send play session transition for all receivers. Thus, the play message (sent to the receiver for the portion of content available at all the receivers) makes synchronization possible for all users (receivers). Currently, transmission data C2 is available with all receivers and still C1 is playing, sender issue 'sync message continue' to all receiver to continue the play session in a playing state. In an embodiment of the disclosure, the content availably corresponds to the availability of a full transmission unit (complete chunk) at the receivers.

[0085] Meanwhile, at operation 726, content transmission of the transmission data C3 is started by the sender.

[0086] At operation 728, the transmission data C3 report is received from the receiver-1. For example, the latency with receiver-1 is α31.

[0087] Further, at operation 730, play session completed playing C2 at all the consumers (sender, receiver). Due to network fluctuation, the receiver reports at the sender indicate that few receivers yet to receive transmission data C3. The sync session at the sender may send buffering message to all participants for indicating state transition from play session at all consumers to buffering state. Now at this phase, the user experience quotient gets determined. The system 200 keeps checking the user experience quotient whenever buffer state transition occurs to improve experience with new mechanism, such as chunk adaptation. As a result, play experience may be smooth for all consumers.

[0088] After some time, transmission report for C3 is received from receiver 2, at operation 732. For example, latency with receiver-2 is α32, also conference latency is measured which is ∂3.

[0089] Further, at operation 734, the sync session message play is sent to other receivers. Thus, the receiver state at all users' side transition to playing state and the user experience quotient gets updated with the play session time in buffering state. Further, the transition count is incremented.

[0090] At operation 736, all users play video based on latency indication in play message.

[0091] After few iterations, the user experience quotient keeps varying based on function (play time / (playtime + transition count *α + time in buffer state * β) at operation 738. Further, α and β are penalty for transition and time in buffering state. If there is no buffering and no transition, user experience quotient is 1. This parameter is crucial to maintain optimal experience for consumers even in network fluctuations. If the experience may't be improved, a particular receiver opts out of synchronization session that is impacting the experience. Thus, the receiver may not impact the other receivers of the sync session.

[0092] If user experience quotient determined going below 0.8 transmission data size is modified by the sender at operation 740. Also, the sender informs all the receivers about this property, transmission data C4 is shared in smaller sizes to adapt and continue the content play even in network degradation and wait for the network to recover.

[0093] After operation 740, if user experience quotient is still going down sender identify which receiver impacted the synchronization session based on transmission reports and remove the user from the sync session to avoid further degradation of consumer experience in the session.

[0094] Figure 8 illustrates a flowchart depicting an operation of the system 200 at the sender UE for managing synchronization in the conference call, according to an embodiment of the disclosure. The system 200 for managing synchronization in the conference call is explained with reference to Figures 2 and 3.

[0095] As depicted, Figure 8 shows the communication at the sender UE 202 / broadcaster / relay end. Once the sender UE 202 start content transmission with transmission unit size (chunk size), the sync session 802 gets establish and the sync session 802 controls the play session 804 based on reports received from N / W 806 (network / receiver UEs). Further, the content sent to receivers goes to the wait buffer 808 for play and the sender UE 202 waits for the play session 804 to indicate resume play to the media player 810.

[0096] Further, a latency unit 812 determines end to end receiver latency of the content streaming and conference based on the RTCP report received from the media server and inform this to the sync session 802. Based on reports received from receiver UEs (via N / W 806) and latency unit 812 details, the sync session 802 in the sender UE 202 sends a message to receiver UEs about play transition and latency parameters. After this, the play session 804 transitions to playing state and informs the wait buffer 808 to resume content playing available in the wait buffer 808.

[0097] Furthermore, the sync session 802 keeps determining user experience quotient and controls transmission size being used for transmission by the content session 814 to optimize "user experience quotient". This process repeats till the entire file is transmitted from the sender UE 202 to receiver and play is completed, at operation 816.

[0098] Figure 9 illustrates a flowchart depicting the operation of the system 200 at a receiver UE for managing synchronization in the conference call, according to an embodiment of the disclosure. The system 200 for managing synchronization in the conference call is explained with reference to Figures 2 and 3.

[0099] As depicted, Figure 9 shows the communication at receiver UE. Once the sender UE 202 start content transmission, the receiver UE initializes the content session 814 with transmission data negotiated (chunk size). Further, the sync session 802 gets established and controls the play session 804 based on sync messages received from the N / W 806 (from sender)

[0100] Further, the content received from the content session 814 goes to the wait buffer 808 for play and the receiver UE waits for the play session 804 to indicate resume play to the media player 810. The latency unit 812 determines and send the RTCP reports to the sender UE 202. Based on the sync messages received from the sender UE 202, the sync session 802 parses and indicate play session 804 transition. After the play session 804 transits to the playing state, the receiver UE informs the wait buffer 808 to resume the content playing available in the wait buffer 808.

[0101] Figure 10 illustrates a block diagram 1000 showing a use-case scenario of the system 200 for managing synchronization in the conference call, according to an embodiment of the disclosure. The system 200 for managing synchronization in the conference call is explained with reference to Figures 2 and 3.

[0102] In an embodiment of the disclosure, the system 200 facilitates distributed content synchronization session　for lossless content viewing (no content omission in play by consumers) in a multi-party conference call with varying network capabilities. All users' content playing positions are synchronized. The system 200 considers latency of the content transmission and exchanges series of synchronization message among the users. In an embodiment of the disclosure, the content play, availability, and play are controlled by the synchronization session and there may be a continuous synchronization between consumers. Further, the system 200 performs the content streaming and synchronization session coordination to modify transmission size, as per play position and content availability at all users. Thereby improving smooth playing experience in variable network conditions at the receiver UE.

[0103] As depicted, the receiver UE is in a good condition and initial transmission size is 10MB (max size). Now all receivers have 10MB (say 10sec) content to play. Further, all users (sender and receiver) start playing content part-1 10MB (10 sec). Further, one of the users is in low bandwidth to download content part-2 of 10MB size which may take 13sec. Remaining users may take lesser time. Thus, after playing part-1 of 10MB (10 sec), part-2 is available after 3 sec from playing the complete chunk-1. To improve the user viewing experience, the chunk adaptation is applied where chunk-2 size is reduced to 8MB. Further, the receiver takes <10 sec to download the content. Accordingly, all receivers have data to play for next 8 sec by the time chunk-1 play is complete. As a result, continuous synchronized play is provided to all the consumers. This is what referred as adaptation as per group capabilities. This downgrade of chunk may continue till it reach min chunk (for example, 3MB). Same way when user bandwidth improves, this transmission size keeps increasing till maximum size.　Here the content transmission and the sync session provide enhanced user experience. The synchronization messages consider latency aspects of the video conference to determine streaming delay. Thereby, improving the user experience (the content that the user is viewing, and what the user is expressing in the video conference).

[0104] Figure 11 illustrates a flow chart showing a use-case scenario of the system 200 for managing synchronization in the conference call, according to an embodiment of the disclosure. The system 200 for managing synchronization in the conference call is explained with reference to Figures 2 and 3.

[0105] In the current use-case scenario, the service is initiated at operation 1102. At 1102, the user A has a local video that the user wants to share with friends (users B and C). All users are already registered in the system 200. Further, the user A creates a room Invite, and shares the created room invite with users B, C. Furthermore, the users B and C join the conference. After users B and C joins the conference using the room invite, the user A browses the file in local file system 200 and starts live video sharing. Further, the user A opts the sync feature.

[0106] At operation 1104, the content streaming session and the sync session are established at all 3 consumers of the conference. Further, the receiver reports are exchanged for content session and conference session.

[0107] Further, at operation 1106, sender sync session (user-A) communicates with receivers (user-B, C) about play time and receiver latency based on receiver reports and conference latency. In this, all receivers and sender start playing the video.

[0108] At operation 1108, if there is a network fluctuation at the receivers' end (one or many), this leads to frequent play transition to play vs buffer states. The user experience quotient is determined, and transmission adaptation happens to improve experience. If the user experience quotient crosses the threshold, the consumer opts out from the sync session.

[0109] Figure 12 illustrates a pictorial depiction 1200 showing a use-case scenario of the system 200 for managing synchronization in the conference call, according to an embodiment of the disclosure. The system 200 for managing synchronization in the conference call is explained with reference to Figures 2 and 3.

[0110] As depicted, the use-case scenario shows share together sharing in an ongoing conference session. The user shares the local file from his phone / TV to share the recorded content. The system 200 enables the immersive experience by providing perfect synchronization of content viewing. Along with synchronization, the disclosure adapts to the conditions (transmission size adaptation) based on all consumer network capabilities. Further, the user experience quotient is used to track play experience. The system 200 also maintains same latency for content streaming and conference to sync user emotions based on the content being viewed. Also, the system 200 may be applied for video over LTE (ViLTE) conference and IP multimedia subsystem (IMS) data channel to provide unique experience to users, such that the users may watch local content in phone without necessarily sharing / uploading the video to others.

[0111] Figure 13 illustrates an exemplary process flow depicting a method for managing synchronization in the conference call, according to an embodiment of the disclosure. The method 900 may be performed by a system 200 implemented in the sender User Equipment (UE) 202, as shown in Figures 2 and 3.

[0112] At operation 1302, the method 1300 includes establishing, by the sender UE 202, a call session associated with the conference call with one or more receiver UEs 203.

[0113] At operation 1304, the method 1300 includes determining, by the sender UE 202, a latency value associated with the established call session for each of the one or more receivers. In determining the latency value, the method 1300 includes transmitting, by the sender UE 202, the one or more data packets of the first size to the one or more receiver UEs 203. Further, the method 1300 includes receiving, by the sender UE 202, at least one of a transmission report from the one or more receivers or a conference report from a server upon transmitting the one or more data packets of the first size to the one or more receiver UEs 203. The method 1300 includes determining, by the sender UE 202, the latency value for each of the one or more receiver UEs 203 based on the received at least one of the transmission report or the conference report.

[0114] At operation 1306, the method 1300 includes determining, by the sender UE 202, a user experience quotient for the call session associated with each of the one or more receivers. In determining the user experience quotient, the method 1300 includes determining the user experience quotient based on play time, buffer time and number of transitions between session states of the one or more receiver UEs 203.

[0115] Further, at operation 1308, the method 1300 includes modifying, by the sender UE 202, a first size of the data packets to a second size for each of the one or more receivers based on a corresponding user experience quotient of the call session associated with the one or more receivers.

[0116] Further, the method 1300 includes transmitting, by the sender UE 202, state session synchronization messages and data packets of a first size to the one or more receiver UEs 203 based on the determined latency value. In an embodiment of the disclosure, the data packets are associated with a media to be played on each of the sender UE 202 and the one or more receiver UEs 203. In transmitting the state session synchronization messages, the method 1300 includes determining, by the sender UE 202, a media state of the media session for the one or more receiver UEs 203 based on the latency value. In an embodiment of the disclosure, the media state is play, pause, or continue the media session on the one or more receiver UEs 203. Further, the method 1300 includes transmitting, by the sender UE 202, the state session synchronization messages associated with the determined media state to the one or more receiver UEs 203 play, pause, or continue the media session on the one or more receiver UEs 203.

[0117] Furthermore, the method 1300 includes determining that the user experience quotient of the call session associated with a receiver UE from the one or more receiver UEs 203 is below a specified threshold. The method 1300 includes removing the receiver UE from the call session upon determining that the user experience quotient of the call session associated with the receiver UE is below the specified threshold.

[0118] While the above operations shown in Figure 13 are described in a particular sequence, the operations may occur in variations to the sequence in accordance with various embodiments of the disclosure. Further, the details related to various operations of Figure 13, which are already covered in the description related to Figures 2-12 are not discussed again in detail here for the sake of brevity.

[0119] The disclosure provides for various technical advancements based on the key features discussed above. The disclosure discloses a system 200 and method for a distributed synchronized session for content streaming and viewing in a multiparty share together conference. The share together conference is provided with adaptable content streaming chunks based on group capabilities for improved user viewing experience. The disclosure defines user experience quotient and identify experience degradation (if any) to take necessary measurements. Further, the disclosure provides synchronized watch together experience for content sharing in the UE. Also, the disclosure provides a server less synchronize experience while sharing / viewing local files from participants. The disclosure provides new experiences in video conference, such as share together where participants may share their personal videos and have conversations.

[0120] In share together service, during a video conference, one of consumers wants to share content (ex: personal video content or OTT) with other consumers. The disclosure enables immersive share connective experience by providing perfect synchronization for the content being watched at all consumers under different conditions (network throughput at sender / receiver & user actions like play / pause). Further, the disclosure transmits the content synchronization and transmission adaptiveness based on group of consumers (sender / receiver) capabilities (network throughput) which may provide improved share together experience for TV / Mobile consumers during the video conference. Further, the disclosure solves multiple problems of the conventional solutions (i.e., continuous synchronization, transmission chunk adaptation, P2P transmission in conference calls, considering both content and call latencies) in conference calls which leads to content skipping, lag and glitches during call session.

[0121] Further, the disclosure facilitates continuous content synchronization (periodic synchronization along with content transmission) unlike conventional synchronization that works after user interaction, such as pause / resume video, and the like. As a result, the disclosure benefits the content streaming / synchronization that works in lossless (no content omission) whereas, conventional solutions sync all participant video to broadcaster thereby the video gets omitted at few consumers which is problematic. The disclosure performs synchronization which consider video conference latency thereby improving view experience (content play viewing latency and conference latency should be same to have better consumer experience). The disclosure performs content streaming which adapts transmission property (ex: chunk size) based on sync session feedback to improve user experience. Further, the disclosure discloses "synchronized content streaming + viewing mechanism" in multi-party conference which consider latency aspect of both content streaming and ongoing conference. Approach defines new synchronization mechanism where content availability, play are controlled at all consumers in distributed manner. Play happens upon content availability at all consumers. There by all consumers sync up with all other consumers without omission of play data. This is achieved with reports of content streaming at synchronization session which enables continuous play position awareness.

[0122] Furthermore, the synchronized share together experience of the disclosure provides immersive view experience particularly in the video conference. The disclosure optimizes latency equivalent conference latency <200ms as compared to >2sec sync observed in existing methodologies. The users view full content without omitting parts of it. The users may experience seamless video share together even in network fluctuation as the disclosure adapts to network at all consumers. This disclosure facilitates video share together experience possible in P2P as this achieves low latency (as without relay, end to end latency is minimal) and low-cost deployment (content server and sync server deployment not required). Also, the disclosure considers the right user experience quotient factor to align transmission of chunks based on network capabilities of the users in the conference call. The disclosure discloses a distributed synchronized session technique for loss less content viewing based on content reports and conference latency. Further, the disclosure performs cross channel latency synchronization to optimize watch together experience based on content sync and video conference latency.

[0123] Further, the disclosure proposes a "synchronized content streaming and viewing mechanism" in multi-party conference which consider latency aspect of both content streaming and ongoing conference. The disclosure defines a new synchronization mechanism where content availability and play are controlled at all consumers in distributed manner. The play happens upon content availability at all consumers. Thereby all consumers sync up with all other consumers without omission of play data. This is achieved with reports of content streaming at synchronization session which enables continuous play position awareness. Further, the disclosure performs perfect synchronization (glitch free) between participants for watch together content in a video conference session. The disclosure performs streaming adaptation based on content view location and dynamic call conditions of the group of participants. The disclosure synchronizes the content streaming and conference else user emotions related to the content view may not be synchronized in the video conference. The disclosure performs continuous synchronization throughout the call unlike existing synchronization that works after user interaction like pause / resume video.

[0124] The plurality of modules 208 may be implemented by any suitable hardware and / or set of instructions. Further, the sequential flow illustrated in Figure 3 is exemplary and the embodiments may include the addition / omission of operations as per the requirement. In some embodiments, the one or more operations performed by the plurality of modules 208 may be performed by the processor / controller based on the requirement.

[0125] While the disclosure has been illustrated and described with reference to various example embodiments, it will be understood that the various example embodiments are intended to be illustrative, not limiting. It will be further understood by those skilled in the art that various changes in form and detail may be made without departing from the true spirit and full scope of the disclosure, including the appended claims and their equivalents. It will also be understood that any of the embodiment(s) described herein may be used in conjunction with any other embodiment(s) described herein.

Claims

1.A method (1300) for managing synchronization in a conference call, the method (1300) comprising:establishing (1302), by a first user equipment (UE) (202), a call session associated with the conference call with one or more second UEs (203);determining (1304), by the first UE (202), a latency value associated with the call session for each of the one or more second UEs (203);determining (1306), by the first UE (202), a user experience quotient for the call session associated with each of the one or more second UEs (203); andmodifying (1308), by the first UE (202), a first size of one or more data packets to a second size for each of the one or more second UEs (203) based on a corresponding user experience quotient of the call session associated with the one or more second UEs (203).2.The method (1300) as claimed in claim 1, wherein determining the latency value comprises:transmitting, by the first UE (202), the one or more data packets of the first size to the one or more second UEs (203);receiving, by the first UE (202), at least one of a transmission report from the one or more second UEs (203) or a conference report from a server upon transmitting the one or more data packets of the first size to the one or more second UEs (203); anddetermining, by the first UE (202), the latency value for each of the one or more second UEs (203) based on the received at least one of the transmission report or the conference report.3.The method (1300) as claimed in claim 1, further comprising:transmitting, by the first UE (202), state session synchronization messages and the one or more data packets of the first size to the one or more second UEs (203) based on the determined latency value, wherein the one or more data packets are associated with a media to be played on each of the first UE (202) and the one or more second UEs (203).4.The method (1300) as claimed in claim 3, wherein transmitting the state session synchronization messages comprises:determining, by the first UE (202), a media state of media session for the one or more second UEs (203) based on the latency value, wherein the media state is one of play, pause, or continue the media session on the one or more second UEs (203); andtransmitting, by the first UE, (202) the state session synchronization messages associated with the media state to the one or more second UEs (203) for one of play, pause, or continue the media session on the one or more second UEs (203).5.The method (1300) as claimed in claim 1, wherein determining the user experience quotient comprises:determining the user experience quotient based on play time, buffer time and number of transitions between session states of the one or more second UEs (203).6.The method (1300) as claimed in claim 1, further comprising:determining that the user experience quotient of the call session associated with a second UE from the one or more second UEs (203) is below a specified threshold; andremoving the second UE from the call session upon determining that the user experience quotient of the call session associated with the second UE is below the specified threshold.7.A first user equipment (UE) (202) for managing synchronization in a conference call, the first UE (202) comprising:memory (210) storing instructions; andone or more processors (204),wherein the instructions, when executed by the one or more processors (204) individually or collectively, cause the first UE to:establish a call session associated with the conference call with one or more second UEs (203);determine a latency value associated with the call session for each of the one or more second UEs (203);determine a user experience quotient for the call session associated with each of the one or more second UEs (203); andmodify a first size of one or more data packets to a second size for each of the one or more second UEs (203) based on a corresponding user experience quotient of the call session associated with the one or more second UEs (203).8.The first UE (202) as claimed in claim 7, wherein in determining the latency value, the instructions, when executed by the one or more processors (204) individually or collectively, cause the first UE to:transmit the one or more data packets of the first size to the one or more second UEs (203);receive at least one of a transmission report from the one or more second UEs (203) or a conference report from a server upon transmitting the one or more data packets of the first size to the one or more second UEs (203); anddetermine the latency value for each of the one or more second UEs (203) based on the received at least one of the transmission report or the conference report.9.The first UE (202) as claimed in claim 7, wherein the instructions, when executed by the one or more processors (204) individually or collectively, cause the first UE to:transmit state session synchronization messages and the one or more data packets of the first size to the one or more second UEs (203) based on the determined latency value, wherein the one or more data packets are associated with a media to be played on each of the first UE (202) and the one or more second UEs (203).10.The first UE (202) as claimed in claim 8, wherein in transmitting the state session synchronization messages, the instructions, when executed by the one or more processors (204) individually or collectively, cause the first UE to:determine, by the first UE (202), a media state of media session for the one or more second UEs (203) based on the latency value, wherein the media state is one of play, pause, or continue the media session on the one or more second UEs (203); andtransmit, by the first UE (202), the state session synchronization messages associated with the media state to the one or more second UEs (203) for one of play, pause, or continue the media session on the one or more second UEs (203).11.The first UE (202) as claimed in claim 7, wherein in determining the user experience quotient, the instructions, when executed by the one or more processors (204) individually or collectively, cause the first UE to:determine the user experience quotient based on play time, buffer time and number of transitions between session states of the one or more second UEs (203).12.The first UE (202) as claimed in claim 7, wherein the instructions, when executed by the one or more processors (204) individually or collectively, cause the first UE to:determine that the user experience quotient of the call session associated with a second UE from the one or more second UEs (203) is below a specified threshold; andremoving the second UE from the call session upon determining that the user experience quotient of the call session associated with the second UE is below the specified threshold.13.A non-transitory computer-readable storage medium storing one or more programs comprising instructions to, when executed by at least one processor of a first user equipment (UE) individually or collectively, cause the first UE to:establish a call session associated with the conference call with one or more second UEs (203);determine a latency value associated with the call session for each of the one or more second UEs (203);determine a user experience quotient for the call session associated with each of the one or more second UEs (203); andmodify a first size of one or more data packets to a second size for each of the one or more second UEs (203) based on a corresponding user experience quotient of the call session associated with the one or more second UEs (203).14.The non-transitory computer-readable storage medium as claimed in claim 13, wherein in determining the latency value, the instructions further cause the first UE to:transmit the one or more data packets of the first size to the one or more second UEs (203);receive at least one of a transmission report from the one or more second UEs (203) or a conference report from a server upon transmitting the one or more data packets of the first size to the one or more second UEs (203); anddetermine the latency value for each of the one or more second UEs (203) based on the received at least one of the transmission report or the conference report.15.The non-transitory computer-readable storage medium as claimed in claim 13, wherein the instructions further cause the first UE to:transmit state session synchronization messages and the one or more data packets of the first size to the one or more second UEs (203) based on the determined latency value, wherein the one or more data packets are associated with a media to be played on each of the first UE (202) and the one or more second UEs (203).

Images