Patent Description:
To meet the demand for wireless data traffic having increased since deployment of <NUM> (<NUM>th-Generation) communication systems, efforts have been made to develop an improved <NUM> (<NUM>th-Generation) or pre-<NUM> communication system. Therefore, the <NUM> or pre-<NUM> communication system is also called a 'beyond <NUM> network' or a 'post LTE system'.

In the <NUM> system, hybrid FSK and QAM modulation (FQAM) and sliding window superposition coding (SWSC) as an advanced coding modulation (ACM), and filter bank multi carrier (FBMC), non-orthogonal multiple access (NOMA), and sparse code multiple access (SCMA) as an advanced access technology have been developed.

MC services are regarded as critical to an operation, such that any disruption or failure with respect to reception of a data pertaining to such service may be catastrophic and probable to cause fatalities since mission-critical service is known to be related to preventing loss of human life and property. For example, MCVideo is one of the services used for mission critical audio-video communication in multi-user environments or multiple location environments. Such services may be used by agencies providing public safety services such as police-services, fire services, and ambulance services. Therefore, in order to help improve public safety-related emergency-situations, mission-critical services need to be rendered with high accessibility, high availability, high reliability, low latency, many real-time operating capabilities, interoperability with other services and systems, private and group communications, the ability to handle emergencies and to provide prioritization, pre-emption, queuing, and an improved quality of service.

In MCVideo systems, there can be multiple MCVideo clients transmitting media streams simultaneously in a single group communication. Consequently, an MCVideo client should be able to receive one or more media streams from the server simultaneously. So, the server should be able to handle the transmission of multiple simultaneous media streams in a single group communication for that MCVideo client, which results in complications in handling the media streams at the MCVideo server.

The transmission control server consists of a "general reception control operation", as described in subclause <NUM>. <NUM> of the <NUM>rd Generation Partnership Project (3GPP) TS <NUM> and "basic reception control operation towards the transmission participant", as described in subclause <NUM>. <NUM> of 3GPP TS <NUM>. These state machines insufficiently handle the transmission of multiple simultaneous media streams in a single group communication for an MCVideo user who is requesting to receive media. Document (<CIT>) discloses a conventional method for a Media Server of delivering media streams to a Client User Equipment for local rendering. In R5-<NUM> discloses test case for MCVideo.

The present disclosure has been made to address the above-mentioned problems and disadvantages, and to provide at least the advantages described below.

According to an aspect of the present disclosure, a method for handling reception of a plurality of media streams in an MC system is provided as defined by appended claims.

According to another aspect of the present disclosure, for handling a plurality of media stream receptions in an MC system, the MC server is provided as defined by the appended claims.

Various embodiments of the present disclosure are described with reference to the accompanying drawings. However, various embodiments of the present disclosure are not limited to particular embodiments, and it should be understood that modifications, equivalents, and/or alternatives of the embodiments described herein can be variously made. With regard to description of drawings, similar components may be marked by similar reference numerals.

The present disclosure relates to a method for handling the reception of a plurality of media streams in MC systems. The present disclosure provides two solutions to address the aforementioned problems, the first solution introduces a new reception controller state which, along with a "stream reception control operation" state machine and a "basic reception control operation towards the transmission participant" state machine, handles complexities in multiple stream scenarios. The second solution introduces a new counter at server to handle complexities related to multiple receptions. Both solutions can be used individually, or a combination of both solutions can be used to solve multiple stream reception complexities at a server.

Further, the present disclosure may relate to an MC server for handling reception of a plurality of media streams in an MC system. In addition, the present disclosure may also relate to a method for handling reception of a plurality of media streams in an MC system.

" Any embodiment or implementation of the present subject matter described as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments.

While the disclosure is susceptible to various modifications and alternative forms, specific embodiments thereof has been shown by way of example in the drawings and will be described in detail below. It should be understood, however that these specific embodiments are not intended to limit the disclosure to the forms disclosed, but on the contrary, the disclosure is to cover all modifications, equivalents, and alternatives falling within the scope of the disclosure.

The terms "comprises", "comprising", "includes", or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a setup, device, or method that comprises a list of components or steps does not include only those components or steps but may include other components or steps not expressly listed or inherent to such a setup, device or method. In other words, one or more elements in a system or apparatus proceeded by "comprises" does not, without more constraints, preclude the existence of other elements or additional elements in the system or method.

The present disclosure relates to a method and MC server for handling reception of a plurality of media streams in an MC system. As disclosed in the Background section, the simultaneous reception of multiple media streams to a particular client results in complications in handling media streams at the MC server.

Thus, the present disclosure discloses how simultaneous reception of multiple media streams may be possible in a single group communication. To this effect, the MC server transmits a request to each of one or more receiving devices associated with the MC server for receiving a plurality of media streams sent from a plurality of transmitting devices. The MC server may receive a response from each of the one or more receiving devices for receiving a number of media streams among the plurality of media streams sent from one or more of the plurality of transmitting devices. The number of media streams accepted by the receiving devices may be updated as a counter value for that particular receiving device and stored at the MC server. The counter value may be incremented by <NUM> for each stream accepted by receiving device and decremented by <NUM> when a previously accepted stream is ended by the receiving device.

Thereafter, the MC server may identify the one or more receiving streams accepted by the receiving device based on an SSRC identifier associated with media streams sent from each of the one or more of the plurality of transmitting devices. Each media stream may be associated with the SSRC identifier. So, based on the SSRC identifier and the counter, the MC server may identify the one or more receiving devices who are intended to receive the media streams from the one or more of the plurality of transmitting devices. Thereafter, the MC server may transmit the media streams based on the mapped SSRC identifier and the counter value to the identified one or more receiving devices. The media streams from the one or more of the plurality of transmitting devices are transmitted to the identified one or more receiving devices until the one or more receiving devices reject the request to receive the plurality of media streams from the one or more of the plurality of transmitting devices.

In addition, the present disclosure enables users to send a request for re-initiating transmission of the plurality of media streams, which are previously rejected, to receive the plurality of media streams from the one or more of the plurality of transmitting devices.

In this manner, in the present disclosure, the MC server solves complexities at the MC server for handling multiple media streams in a single group communication.

<FIG> illustrate environments for handling reception of a plurality of media streams in an MC system, according to various embodiments.

Referring to <FIG>, the environment <NUM> includes one or more transmitting devices <NUM><NUM> to 101n (collectively referred as transmitting devices <NUM>), an MC server <NUM>, one or more receiving devices <NUM><NUM> to 105n (collectively referred as receiving device <NUM>), and users associated with each of the transmitting devices <NUM> and the receiving devices <NUM>. The MC server <NUM> may be employed in mission critical services used for mission critical audio-video communication in a multi-user environment or multiple location environment. The MC server <NUM> may be employed in services with a multi-user environment or a multi-location environment. The MC server <NUM> may be a server or a network entity.

A media controller may act as the MC server <NUM>. As shown in <FIG>, the media controller <NUM> may be part of the MC server <NUM>. The one or more transmitting devices <NUM> and the one or more receiving devices <NUM> may be associated with corresponding users. The one or more transmitting devices <NUM> and the one or more receiving devices <NUM> may be electronic devices which may include a mobile phone, a desktop computer, a tablet, and a laptop. One or more group may comprise one or more transmitting devices <NUM> and one or more receiving devices <NUM>. In addition, a method of the present disclosure may be explained by considering one group among the one or more groups, and the method may be applicable for each of the one or more groups as well for managing the media stream reception. The media stream may include, but is not limited to, text, audio, video, and images.

The MC server <NUM> may transmit a request to each of the one or more receiving devices <NUM> for receiving a plurality of media streams, sent from plurality of transmitting devices <NUM>. Thereafter, the MC server <NUM> may receive response from each of the one or more receiving devices <NUM> for receiving a number of media streams among the plurality of media streams sent from one or more of the plurality of transmitting devices <NUM>. The information about the number of media streams may be stored or updated as a counter value for each of the one or more receiving devices <NUM> in a database associated with the MC server <NUM>. The counter value may be a numerical value which is updated based on the number of media streams accepted or rejected by each of the one or more receiving devices <NUM>. If the receiving device accepts a request to receive <NUM> media streams from the transmitting devices <NUM>, then the counter value may be <NUM>. If the receiving device later rejects the request to receive the media stream of an already accepted stream from one of the transmitting devices, then the counter value may be updated to <NUM>. Thereafter, the MC server <NUM>, may identify one or more receiving devices <NUM> who are intended to receive the media streams from the one or more of the plurality of transmitting devices <NUM> based on an SSRC identifier and counter value. Each media stream from the plurality of transmitting devices <NUM> is associated with the SSRC identifier.

The SSRC identifier may comprise information about the receiving stream that is intended to be received from the transmitting device. Once the one or more receiving devices <NUM> are identified, the MC server <NUM> may transmit the media streams from one or more of the plurality of transmitting devices <NUM> to the identified one or more receiving devices <NUM> based on the mapped SSRC identifier, and also based on the counter value. The MC server <NUM> may transmit the media streams from the one or more of the plurality of transmitting devices <NUM> to the identified one or more receiving devices <NUM> until the one or more receiving devices <NUM> rejects the request to receive the plurality of media streams from the one or more of the plurality of transmitting devices <NUM>.

The one or more receiving devices <NUM> may send a request to the MC server <NUM> for re-initiating transmission of the plurality of media streams that were previously rejected. Upon receiving the request, the MC server <NUM> may check if the one or more of the plurality of transmitting devices <NUM> are still transmitting the media streams, and if so, then those media streams may be transmitted to the one or more receiving devices <NUM>. However, if the one or more transmitting devices <NUM> terminate transmitting the media streams, then the MC server <NUM> may transmit a notification message to each of the one or more receiving devices <NUM> indicating that the one or more transmitting devices <NUM> has terminated the process of transmitting the media streams.

<FIG> illustrates a block diagram of an MC server for handling reception of a plurality of media streams in an MC system, according to an embodiment.

Referring to <FIG>, the MC server <NUM> includes an I/O interface <NUM>, a processor <NUM>, and a memory <NUM>. The I/O interface <NUM> may be configured to send/receive a request regarding media stream transmission. The processor <NUM> may be configured to handle a plurality of media stream receptions. The MC server <NUM> includes data <NUM> and modules <NUM>. As shown in the <FIG>, the data <NUM> is stored in the memory <NUM> that is configured in the MC server <NUM>. The data <NUM> may include SSRC identifier data <NUM>, counter value data <NUM> and other data <NUM>.

The data <NUM> may be stored in the memory <NUM> in the form of various data structures. Additionally, the data <NUM> can be organized using data models, such as relational or hierarchical data models. The other data <NUM> may store temporary data and temporary files generated by the modules <NUM> for performing the various functions of the MC server <NUM>.

The data <NUM> stored in the memory <NUM> may be processed by the modules of the system <NUM>. The modules <NUM> may be stored within the memory <NUM>. The modules <NUM> may be communicatively coupled to the processor <NUM> and may be configured in the MC server <NUM>, which may also be present outside the memory <NUM>, as shown in <FIG> and implemented as hardware.

As used herein, the term "module" may refer to an application specific integrated circuit (ASIC), an electronic circuit, a processor (a shared processor, a dedicated processor, or a group processor) and a memory that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable components that provide the described functionality.

Referring to <FIG>, the modules <NUM> include a receiving module <NUM>, a transmitting module <NUM>, an identification module <NUM> and other modules <NUM>. The other modules <NUM> may be used to perform various miscellaneous functions of the MC server <NUM>. It will be appreciated that such aforementioned modules may be represented as a single module or a combination of different modules.

Furthermore, a person of ordinary skill in the art will appreciate that in an implementation, the one or more modules <NUM> may be stored in the memory <NUM>, without limiting the scope of the disclosure. Modules <NUM>, when configured with the functionality defined in the present disclosure, will result in a novel hardware.

The receiving module <NUM> may be configured to receive a request or response from the one or more receiving devices <NUM>.

The transmitting module <NUM> may be configured to transmit a request to each of the one or more receiving devices <NUM> for receiving media streams sent from plurality of transmitting devices <NUM>. Also, the transmitting module <NUM> may be configured to transmit media streams to one or more receiving devices <NUM>. There may be four transmitting devices <NUM> and two receiving devices <NUM> in a group that is associated with the MC server <NUM>, as shown in <FIG>.

<FIG> illustrates handling reception of a plurality of media streams in an MC system, according to an embodiment.

Referring to <FIG>, four transmitting devices <NUM> include transmitting device <NUM><NUM><NUM>, transmitting device <NUM><NUM><NUM>, transmitting device <NUM><NUM><NUM> and transmitting <NUM><NUM><NUM>. Two receiving devices <NUM> include receiving device <NUM><NUM><NUM> and receiving device <NUM><NUM><NUM>. The transmitting device <NUM><NUM><NUM> may be configured to transmit the media stream <NUM>. Similarly, the transmitting device <NUM><NUM><NUM> may be configured to transmit media stream <NUM>, transmitting device <NUM><NUM><NUM> may be configured to transmit media stream <NUM><NUM><NUM> and the transmitting device <NUM><NUM><NUM> may be configured to transmit the media stream <NUM>. The MC server <NUM> may send a request to the receiving device <NUM><NUM><NUM> and the receiving <NUM><NUM><NUM> device, as shown in <FIG>.

Upon receiving the request, the receiving device <NUM><NUM><NUM> accepts the request to receive the media stream from transmitting device <NUM><NUM><NUM> and transmitting device <NUM><NUM><NUM>. Therefore, the counter value for the receiving device <NUM><NUM><NUM> may be updated as "<NUM>", as the receiving device <NUM><NUM><NUM> has accepted to receive one media stream (media stream <NUM>) from the transmitting device <NUM><NUM><NUM> and one media stream (media stream <NUM>) from the transmitting device <NUM><NUM><NUM>. Similarly, the receiving device <NUM><NUM><NUM> accepts the request to receive the media stream from transmitting device <NUM><NUM><NUM> and transmitting device <NUM><NUM><NUM>. Therefore, the counter value for the receiving device <NUM> is updated as "<NUM>", as the receiving device <NUM><NUM><NUM>, has accepted to receive one media stream (media stream <NUM>) from the transmitting device <NUM><NUM><NUM> and one media stream (media stream <NUM>) from the transmitting device <NUM><NUM><NUM>.

The range of counter values can be set statically or dynamically. Range refers to the set of values between a maximum and minimum value of the counter. A group call range can be the same for all receiving devices <NUM> or it can be different for each of the one or more receiving devices <NUM>. If the range is statically set, then counter values are fixed and will not change throughout the group call.

For example, for receiving device <NUM>, counter max value is set to <NUM> in MC server <NUM> in a group call. Receiving device <NUM> can receive a maximum of two streams from transmitting device <NUM>. If receiving device <NUM> tries to accept a third stream, then the third stream request will be rejected from MC server <NUM>. The range of counter values is dynamically configured for each of the one or more receiving devices <NUM> based on parameters, which may include, but are not limited to, a type of receiving device, a priority of a user associated with the receiving device and the network load associated with the receiving device.

The range of counter values can change in between the group call for each of one or more receiving device. For example, the minimum counter value associated with the receiving device <NUM><NUM><NUM> is <NUM> and the maximum counter value associated with the receiving device <NUM><NUM><NUM> is <NUM>. Further, the minimum counter value associated with the receiving device <NUM><NUM><NUM> is <NUM> and the maximum counter value associated with the receiving device <NUM> is <NUM>. Therefore, the MC server <NUM> has rejected transmission of media streams from the transmitting device <NUM><NUM><NUM> and the transmitting device <NUM><NUM><NUM> to be received by receiving device <NUM><NUM><NUM> because the MC server <NUM> is already receiving the media stream from the transmitting device <NUM><NUM><NUM> and the transmitting device <NUM><NUM><NUM>. In addition, the MC server <NUM> has rejected transmission of the media stream from the transmitting device <NUM><NUM><NUM> and the transmitting device <NUM><NUM><NUM> to the receiving device <NUM><NUM><NUM> because the MC server <NUM> is already receiving the media streams from the transmitting device <NUM><NUM><NUM> and the transmitting device <NUM><NUM>.

The MC server <NUM> may decide the maximum and minimum counter values, and the counter values may be dynamically changed within the minimum counter value and the maximum counter value by the MC server <NUM> based on network condition/load, user information and device information. The counter value may be stored as counter value data <NUM>. Table <NUM>, below, may indicate the counter value for various device types, users, and network loads.

Once the response is received from the receiving devices <NUM>, the MC server <NUM>, using the identification module <NUM>, may identify the one or more receiving devices <NUM> in the group which is configured to receive the media streams from the transmitting devices <NUM> based on the SSRC identifier associated with the media streams of each of the one or more of the plurality of transmitting devices <NUM> and the counter value. Each media stream is associated with the SSRC identifier, which may be stored as SSRC identifier data <NUM>.

Using the SSRC identifier, the MC server <NUM> may identify the receiving devices <NUM> which are configured to receive the intended media streams. The MC server <NUM> may identify the receiving device <NUM> for receiving the media streams from the transmitting device <NUM> and the transmitting device <NUM>. The MC server <NUM> may identify the receiving device <NUM> for receiving the media stream from the transmitting device <NUM> and the transmitting device <NUM>. Based on the mapped SSRC identifier and the counter value, the MC server <NUM> may transmit the media streams from the transmitting devices <NUM> to the receiving devices <NUM>.

In the example above, the MC server <NUM> transmits the media streams from the transmitting device <NUM> and the transmitting device <NUM> to the receiving device <NUM>, and transmits the media streams from the transmitting device <NUM> and the transmitting device <NUM> to the receiving device <NUM>. The MC server <NUM> transmits the media streams to the receiving devices <NUM> until the receiving devices <NUM> rejects the request to receive the plurality of media streams from the transmitting devices <NUM>. Additionally or alternatively, the receiving device <NUM> may reject the request to receive the media stream from the transmitting device <NUM>. Therefore, the receiving device <NUM> may stop the media stream transmitting from the transmitting device <NUM>. At this stage, the counter value may be updated to "<NUM>", as the receiving device <NUM> has rejected receiving the media stream from the transmitting device <NUM> but still is receiving a media stream from the transmitting device <NUM>.

Further, the receiving device <NUM> may request the MC server <NUM> for re- initiating transmission of the media stream from the transmitting device <NUM>. Upon receiving the request, the MC server <NUM> may check whether the transmitting device <NUM> is still transmitting the media stream. If the media stream is still being transmitted by the transmitting device <NUM>, then the MC server <NUM> may transmit media stream from transmitting device <NUM> to the receiving device <NUM> and update the counter value accordingly. Therefore, the counter value may be updated based on the number of media streams accepted or rejected by each of the one or more receiving devices <NUM>. In addition, the counter value for a particular receiving device may be incremented by <NUM> for each stream accepted by that device and decremented by <NUM> when a previously accepted stream is ended (or reception is refused) by that particular receiving device. The counter value indicates the active receiving stream count for a particular receiving device. When any of the transmitting devices <NUM> terminate transmission of the plurality of media streams, the MC server <NUM> transmits a notification message to the receiving devices <NUM> in the group, and the counter value will be decremented by <NUM> for one or more active receiving devices <NUM>.

The present disclosure provides two solutions for the MC server <NUM> to handle multiple media streams in a single group communication problem, the first solution uses a reception controller state and state machine to handle complexities for multiple stream scenarios. The second solution uses a counter and a state machine transaction at the MC server <NUM> to handle such complexities.

<FIG> illustrate state diagrams of methods of using a reception controller state and server state machines for handling reception of a plurality of media streams in an MC system, according to various embodiments.

In particular, <FIG> illustrates a state diagram for "transmission control server, basic reception control operation towards the transmission participant". <FIG> shows the state diagram for "transmission control server stream reception control operation towards the transmission participant". The reception control arbitration logic in the MC server <NUM> shall keep one instance of the "basic reception control operation towards the transmission participant" state machine per user associated with the receiving devices <NUM>, and shall create one instance of the "stream reception control operation towards the transmission participant" state machine for each media transmission notification message sent to the user.

The reception control interface towards the MCVideo client in the transmission control server (e.g., the MC server <NUM>) shall create one instance of the "basic reception control operations" state machine towards the MCVideo client for every transmission participant served by the MC server <NUM>, and shall create one instance of the "stream reception control operation towards the transmission participant" state machine for each "media transmission notification message" <NUM> received from reception control arbitration logic.

Referring to <FIG>, at "start-stop" state <NUM>, this state is part of the MC server <NUM>. When a new instance of the "basic reception control operations towards the transmission participant" state machine is created, before any reception control related input is applied, the state machine is in the "start-stop" state <NUM>. Similarly, when the call is released the state machine shall return to the "start-stop" state <NUM>. An association between the MC server <NUM> and a transmission participant in the MCVideo client is created when the state machine is created; and when one of the following two (<NUM>) events occur:.

When the SIP Session is established and if the session is a normal group call session, then if an MCVideo client initiates an MCVideo call, and the MCVideo call does not exist yet, the transmission control interface towards the MCVideo client in the MC server <NUM> shall initialize a general state machine; or shall enter into a "reception controller" state <NUM>. If the associated transmission participant attempts to initiate an already existing MCVideo call or an MCVideo client rejoins an ongoing MCVideo call or if the MCVideo client is invited to the MCVideo call, then if no MCVideo client has the permission to send media, the transmission control interface towards the MCVideo client in the MC server <NUM> shall create a "basic reception control operations towards the transmission participant" state machine or shall enter into a "reception controller" state <NUM>.

If other MCVideo clients have permission to send a media, the transmission control interface towards the MCVideo client in the MC server <NUM> shall create "basic reception control operations towards the transmission participant" state machine and enter into a "reception controller" state <NUM>; or shall send a media transmission notification to the participant.

The "releasing" state <NUM> is part of the MC server <NUM> "basic reception control operation towards the transmission participant" state machine. The reception control interface towards the MCVideo client in the MC server <NUM> uses this state while waiting for the application and signaling plane to finalize the release of the MCVideo call or finalizing the removal of the MCVideo client from the MCVideo call.

Further, upon receiving an MCVideo call release request from the application and signaling plane, the reception control interface towards the MCVideo client in the MC server <NUM> shall request the network media interface to release all resources associated with this MCVideo client for this MCVideo call; shall terminate all "stream reception control operation towards the transmission participant" state machine instances associated with transmission participant; and shall enter the "start-stop" state <NUM> and terminate the "basic reception control operation towards the transmission participant" state machine associated with this transmission participant.

In the "reception controller" state <NUM>, this part of the MC server <NUM> state is transitioned for the "basic reception control operation towards transmission participant" state machine. The MC server <NUM> is in this state to handle transmission notification messages received from reception control arbitration logic. All reception control messages targeted for a particular transmission participant first received in this state and later for further processing received messages will be diverted to a corresponding "stream reception control" state machine based on "User ID and the SSRC" of user transmitting the media streams.

When the MC server <NUM> server has received real time protocol (RTP) media packets from another transmission participant, or upon receiving a media transmission notification message from the reception control arbitration logic, the reception control interface towards the MCVideo client in the MC server <NUM> shall send the media transmission notification message to the transmission participant; shall include the user ID and the SSRC of the user transmitting the media in the media transmission notification message; may set the first bit in the subtype of the media transmission notification message to "<NUM>" (acknowledgment is required); initiate an instance of a "stream reception control operations towards the transmission participant" state machine; shall map the stored User ID and the SSRC of the user transmitting the media with an instance of "stream reception control operations towards the transmission participant"; and shall remain in the " reception controller" state <NUM>.

In the "U: not permitted to receive" state <NUM>, as shown in <FIG>, this state is part of the MC server <NUM> "stream reception control operation towards the transmission participant" state machine, the transmission control interface towards the MCVideo client in the MC server <NUM> uses this state when the associated transmission participant is not permitted to receive media and is waiting for the response to a transmission notification message.

Referring to <FIG>, upon receiving the "media reception end response message" from the transmission participant, the transmission control interface towards the MCVideo client in the MC server <NUM> shall remain in "U: not permitted to receive" state <NUM>.

In the "U: not permitted to receive" state <NUM>, upon receiving a "receive media request message" from the associated transmission participant, the transmission control interface towards the MCVideo client in the MC server <NUM> shall, if the session is not a broadcast group call, forward the receive media request message to the reception control server arbitration logic; and if the reception control server arbitration logic decides that the transmission participant cannot receive media, send a receive media response (Rejected) message to the associated transmission participant. The receive media response (Rejected) message shall include in the result field the <Result indicator> value result#<NUM> (Rejected) and shall include in the reject cause field the <Reject Cause> value: cause#<NUM> (Insufficient downlink bandwidth); or cause#<NUM> (No permission to receive).

The receive media response (Rejected message may include, in the reject cause field, an additional text string explaining the reason for rejecting the transmission request in the <Reject Phrase> value; may set the first bit in the subtype of the transmission response (Rejected) message to "<NUM>" (acknowledgment is required); if a group call is a broadcast group call, a system call, an emergency call, an imminent peril call, or a temporary group session, shall include the transmission indicator field with appropriate indications; and shall remain in a "U: not permitted to receive" state.

In the "U: not permitted to receive" state <NUM>, upon receiving a "receive media request message" from the associated transmission participant including a reception priority field, the reception priority shall be the lower than the reception priority included in receive media request message and the negotiated maximum reception priority that the MCVideo client is permitted to request.

In the "U: not permitted to receive" state <NUM>, when the MC server <NUM> has stopped receiving media streams from another transmission participant on an uplink, the reception transmission control interface towards the MCVideo client in the MC server <NUM> shall send the transmission end notify message to the transmission participant; shall include the SSRC of the user transmitting the media in the transmission end notify message; and shall enter "U: terminated" state <NUM>.

In the "U: not permitted to receive" state <NUM>, reception control arbitration logic in the MCVideo server decides to grant permission to the transmission participant to receive the media, the transmission control interface towards the MCVideo client in the transmission control server shall send the receive media response (Granted) message to the associated transmission participant, and shall enter the "U: permitted to receive" state <NUM>.

The "U: permitted to receive" state <NUM> is part of the MC server <NUM> "stream reception control operation towards the transmission participant" state machine. The reception transmission control interface towards the MCVideo client in the MC server <NUM> uses this state when the associated transmission participant has been given permission to receive media streams.

In the "U: permitted to receive" state <NUM>, when transmission control server has stopped receiving RTP media packets from another transmission participant on an uplink, the reception transmission control interface towards the MCVideo client in the MC server <NUM> shall send the transmission end notify message to the transmission participant; shall include the SSRC of the user transmitting the media in the transmission end notify message; and shall enter "U: terminated" state <NUM>.

In the "U: permitted to receive" state <NUM>, when the MC server <NUM> determines to end sending the RTP media packets on a downlink to the transmission participant, the reception control interface towards the MCVideo client in the MC server <NUM> shall stop sending the media streams to the transmission participant; shall send the media reception end response message to the transmission participant, and may set the first bit in the subtype of the media reception end response message to "<NUM>"; and shall enter into a "U: not permitted to receive" state <NUM>.

The "U: terminated" is part of the MC server <NUM> "stream reception control operation towards the transmission participant" state machine. Upon entering this state, the MC server <NUM> shall release any downlink resources associated with the transmission participant's stream; shall delete the instance of this "stream reception control operation towards the transmission participant" state machine; and, if the session was initiated as a broadcast group call, shall indicate a "MC server <NUM> basic reception control operation towards the transmission participant" state machine to move to a "releasing" state.

<FIG> illustrate state diagrams of methods of using counter and server state transitions for handling reception of multiple media streams by the MC server, according to various embodiments.

The reception control arbitration logic in the MC server <NUM> shall keep one instance of the "general transmission control operation" state machine per MCVideo call and shall keep one instance of the "basic reception control operations" state machine towards the MCVideo client for every transmission participant served by the MC server <NUM>.

Referring to <FIG>, the "Gr: reception accepted" state <NUM> is part of MC server <NUM> general reception control operation state machine.

In the "Gr: reception accepted" state <NUM>, upon receiving a media transmission request notify message from the reception control arbitration logic in the MC server <NUM>, the MC server <NUM> shall send the media transmission notify message to all other transmission participants. If a group call is a broadcast group call, system call, emergency call, an imminent peril call, the media transmission notify message shall include the reception mode with the reception mode field set to "<NUM>" to indicate an automatic reception mode. If a group call is not a broadcast group call, system call, emergency call or an imminent peril call, the media transmission notify message shall include the reception mode with the reception mode field set to "<NUM>" to indicate a manual reception mode. In addition, the MC server <NUM> shall remain in the "Gr: reception accepted" state <NUM>.

When an SIP Session is established and if the session is a normal group call session, then if an MCVideo client initiates an MCVideo call, and the MCVideo call does not exist yet, the transmission control interface towards the MCVideo client in the MC server <NUM> shall initialize a general state machine; and shall enter the "U: not permitted to receive" state <NUM>.

If the associated transmission participant attempts to initiate an already existing MCVideo call, an MCVideo client rejoins an ongoing MCVideo call, or if the MCVideo client is invited to the MCVideo call, then if no MCVideo client has the permission to send media, the transmission control interface towards the MCVideo client in the MC server <NUM> shall enter the "U: not permitted to receive" state <NUM>. On the other hand, if other MCVideo clients have permission to send media, the transmission control interface towards the MCVideo client in the MC server <NUM> shall enter the "U: not permitted to receive" state <NUM>, and shall send a media transmission notification.

The "U: not permitted to receive" state <NUM> is part of MC server <NUM> basic reception control operation state machine. The transmission control interface towards the MCVideo client in the MC server <NUM> uses this state when the associated transmission participant is not permitted to receive media streams. When entering the "U: not permitted to receive" state <NUM>, the transmission control interface towards the MCVideo client in the MC server <NUM> shall set the state for the associated transmission participant to "U: not permitted to receive"; shall initialize the counter value (herein referred to as C9) (Reception Active) to <NUM>; and shall empty the active SSRC list.

In the "U: not permitted to receive" state <NUM>, when the MC server <NUM> has received media packets from another transmission participant or upon receiving a media transmission notification message from the reception control arbitration logic, the transmission control interface towards the MCVideo client in the MC server <NUM> shall send the media transmission notification message to the transmission participant; shall include the user ID and the SSRC of a user transmitting the media in the media transmission notification message; and shall remain in the "U: not permitted to receive" state <NUM>. In addition, transmission control interface towards the MCVideo client in the MC server <NUM> may set the first bit in the subtype of the media transmission notification message to "<NUM>" (Acknowledgment is required). Additionally, the receipt of the transmission control Ack message and what action to take if the transmission control Ack message is not received may be adjusted.

In the "U: not permitted to receive" state, when the reception MC server <NUM> arbitration logic in the MCVideo server decides to grant permission to the transmission participant to receive the media, the transmission control interface towards the MCVideo client in the MC server <NUM> shall send the receive media response (Granted) message to the associated transmission participant; shall increase counter C9 value by <NUM> if it has not reached its upper limit; shall store the SSRC of transmission participant granting the permission to send media in the active SSRC list until the associated transmission is ended towards participant; and shall enter the "U: permitted to receive state. In addition, the transmission control interface towards the MCVideo client in the MC server <NUM> may set the first bit in the subtype of the receive media response (Granted) message to "<NUM>" (Acknowledgment is required).

In the "U: not permitted to receive" state <NUM>, when MC server <NUM> has stopped receiving media stream from another transmission participant on an uplink, or upon receiving a transmission end notify message from the reception control arbitration logic, the transmission control interface towards the MCVideo client in the MC server <NUM> shall send the transmission end notify message to the transmission participant; shall include the SSRC of the user transmitting the media in the transmission end notify message; and shall remain in the "U: not permitted to receive" state <NUM>.

The "U: permitted to receive" state <NUM> is part of MC server <NUM> basic reception control operation state machine. The MC server <NUM> uses this state when the associated transmission participant has been given permission to receive media. When entering this state, the transmission control interface towards the MCVideo client in the MC server <NUM> shall set the state for the associated transmission participant to "U: permitted to receive".

In the "U: permitted to receive" <NUM> state, upon the decision of the reception control arbitration logic to permit the transmission participant to receive a media in transmission, the transmission control interface towards the MCVideo client in the MC server <NUM> shall request the network media interface in the MCVideo server to forward media stream to the media distributor in the MCVideo server if received packet SSRC is present in the active SSRC list; shall discard the RTP media packets if received packet SSRC is not in the active SSRC list; and shall remain in the "U: permitted to receive" state <NUM>.

In the "U: permitted to receive" state <NUM>, when the MC server <NUM> has received a media stream from another transmission participant on an uplink or upon receiving a media transmission notification message from the reception control arbitration logic, the transmission control interface towards the MCVideo client in the MC server <NUM> shall send the media transmission notification message to the transmission participant; shall include the user ID and the SSRC of user transmitting the media in the media transmission notification; and shall remain in the "U: permitted to receive" state <NUM>.

In the "U: permitted to receive" state <NUM>, when MC server <NUM> has stopped receiving media streams from another transmission participant on an uplink, the transmission control interface towards the MCVideo client in the MC server <NUM> shall send the transmission end notify message to the transmission participant; shall include the SSRC of the user transmitting the media in the transmission end notify message; and shall remove SSRC of the user transmitting the media from Active SSRC list. In addition, if SSRC of the user transmitting the media present in an active SSRC list, then the counter C9 shall be decreased by a value of <NUM> if it has not reached its lower limit. Additionally, if counter C9 value has not reached its lower limit, the transmission control interface towards the MCVideo client in the MC server <NUM> shall remain in the "U: permitted to receive" state <NUM>. In addition, if the counter C9 value has reached it lower limit, the transmission control interface towards the MCVideo client in the MC server <NUM> shall enter the "U: not permitted to receive" state <NUM>.

In the "U: permitted to receive" state <NUM>, when the MC server <NUM> determines to end sending the RTP media packets on a downlink to the transmission participant, the transmission control interface towards the MCVideo client in the MC server <NUM> shall stop sending the media streams to the transmission participant; shall send the media reception end request message to the transmission participant; shall include the SSRC of the user transmitting the media in the media reception end request message; and shall remove SSRC of the user transmitting the media from Active SSRC list. If the SSRC of the user transmitting the media is present in the active SSRC list, then the transmission control interface towards the MCVideo client in the MC server <NUM> shall decrease the counter C9 value (Reception Active) by <NUM> if it has not reached its lower limit. In addition, if the counter C9 value has not reached its lower limit, the transmission control interface towards the MCVideo client in the MC server <NUM> shall remain in the "U: permitted to receive" state <NUM>. Additionally, if the counter C9 value has reached its lower limit, the transmission control interface towards the MCVideo client in the MC server <NUM> shall enter the "U: not permitted to receive" state <NUM>.

In the "U: permitted to receive" state <NUM>, when the MC server <NUM> determines to end sending the RTP media packets on a downlink to the transmission participant, the transmission control interface towards the MCVideo client in the MC server <NUM> shall stop sending the media stream to the transmission participant; shall send the media reception end response message to the transmission participant, and may set the first bit in the subtype of the media reception end response message to "<NUM>" (Acknowledgment is required); and shall remove the SSRC of the user transmitting the media from the active SSRC list. If the SSRC of the user transmitting the media is present in Active SSRC list, then the transmission control interface towards the MCVideo client in the MC server <NUM> shall decrease the counter C9 (Reception Active) value by <NUM> if it has not reached its lower limit. In addition, if the counter C9 value has not reached it lower limit, the transmission control interface towards the MCVideo client in the MC server <NUM> shall remain in the "U: permitted to receive" state <NUM>. Additionally, if the counter C9 value has reached its lower limit, the transmission control interface towards the MCVideo client in the MC server <NUM> shall enter the "U: not permitted to receive" state <NUM>.

In the "U: permitted to receive" state <NUM>, upon receiving a receive media request message from the associated transmission participant, the transmission control interface towards the MCVideo client in the MC server <NUM> shall reject the request if the counter C9 value (Reception Active) has reached its upper limit, and shall skip the forwarding of a receive media request message to the reception control server arbitration logic. If the session is not a broadcast group call, the transmission control interface towards the MCVideo client in the MC server <NUM> shall forward the receive media request message to the reception control server arbitration logic. In addition, if the reception control server arbitration logic decides that the transmission participant cannot receive media, the transmission control interface towards the MCVideo client in the MC server <NUM> shall send a receive media response (Rejected) message to the associated transmission participant.

The receive media response (Rejected) message shall include, in the result field, the <Result indicator> value, result#<NUM> (Rejected); and shall include, in the reject cause field, the <Reject Cause> value cause#<NUM> (Insufficient downlink bandwidth), cause#<NUM> (No permission to receive), or cause#<NUM> (Max number of simultaneous streams that can be received is reached). In addition, the receive media response (Rejected) message may include, in the reject cause field, an additional text string explaining the reason for rejecting the transmission request in the <Reject Phrase> value. Additionally, the receive media response (Rejected) message may set the first bit in the subtype of the transmission response (Rejected) message to "<NUM>" (Acknowledgment is required). In addition, if a group call is a broadcast group call, a system call, an emergency call, an imminent peril call, or a temporary group session, the receive media response (Rejected) message shall include the transmission indicator field with appropriate indications.

Additionally, the transmission control interface towards the MCVideo client in the MC server <NUM> shall remain in the "U: permitted to receive" state <NUM>.

Upon receiving a receive media request message from the associated transmission participant including a reception priority field, the reception priority shall be lower than the reception priority included in a receive media request message and the negotiated maximum reception priority that the MCVideo client is permitted to request.

In the "U: permitted to receive" state <NUM>, when the reception control server arbitration logic in the MCVideo server decides to grant permission to the transmission participant to receive the media, the transmission control interface towards the MCVideo client in the MC server <NUM> shall send the receive media response (Granted) message to the associated transmission participant; shall increase counter C9 value (Reception Active) by <NUM> if it has not reached its upper limit; shall store the SSRC of a transmission participant granting the permission to send media in the active SSRC list until the participant's associated transmission is ended; and shall remain in the "U: permitted to receive" state <NUM>. In addition, the transmission control interface towards the MCVideo client in the server <NUM> may set the first bit in the subtype of the receive media response (Granted) message to "<NUM>" (Acknowledgment is required).

In the "U: permitted to receive" state <NUM>, upon receiving the media reception end response message from the transmission participant, the transmission control interface towards the MCVideo client in the MC server <NUM> shall release any downlink resources associated with the requested media reception for the transmission participant; and shall remain in the "U: permitted to receive" state <NUM>.

The "releasing" state <NUM> is part of the transmission control server "basic reception control operation towards the transmission participant" state machine. The reception control interface towards the MCVideo client in the MC server <NUM> uses this state while waiting for the application and signaling plane to finalize the release of the MCVideo call or finalize the removal of the MCVideo client from the MCVideo call.

Upon receiving an MCVideo call release request from the application and signaling plane, the reception control interface towards the MCVideo client in the MC server <NUM>, shall request the network media interface to release all resources associated with this MCVideo client for this MCVideo call; and shall enter the "Start-stop" state <NUM> and terminate the "basic reception control operation towards the transmission participant" state machine associated with this transmission participant.

When a maximum number of media stream to receive is reached for a receiving device <NUM>, the <Reject cause> value is set to "<NUM>", which indicates that the MC server <NUM> cannot grant the receive media request due to a maximum number of simultaneous received streams having been reached.

A C9 (active reception per-participant) counter is used in MC server <NUM>. The MC server <NUM> stores a count of a plurality of streams accepted by a particular receiving device for a group call. Table <NUM>, below, provides additional details of the C9 counter.

<FIG> illustrates a flowchart of a method for handling reception of a plurality of media streams in an MC system, according to an embodiment of the present disclosure.

Referring to <FIG>, the method includes one or more blocks illustrating a method for handling reception of a plurality of media streams at an MC server <NUM>. The method may be described in the general context of computer executable instructions. Generally, computer executable instructions can include routines, programs, objects, components, data structures, procedures, modules, and functions, which perform specific functions or implement specific abstract data types.

The order in which the method is described is not intended to be construed as a limitation, and any number of the described method blocks can be combined in any order to implement the method. Additionally, individual blocks may be deleted from the methods without departing from the scope of the subject matter described herein. Furthermore, the method can be implemented in any suitable hardware, software, firmware, or combination thereof.

At step <NUM>, the MC server <NUM> transmits a request to each of one or more receiving devices <NUM> for receiving a plurality of media streams sent from the plurality of transmitting devices <NUM>.

At step <NUM>, the MC server <NUM> receives a response from each of the one or more receiving devices <NUM> for receiving a number of media among the plurality of media streams from one or more of the plurality of transmitting devices <NUM>, and updates a number of media streams to be received by each of the one or more receiving devices <NUM> as a counter value.

The counter value may be a numerical value which is updated based on number of media streams accepted or rejected by each of the one or more receiving devices <NUM>. The counter value may be incremented by <NUM> for each media stream accepted by the receiving device <NUM> and decremented by <NUM> when a previously accepted media stream is ended by the receiving device <NUM>. In addition, if the receiving device <NUM> accepts a request to receive two media streams from the transmitting devices <NUM>, then the counter value may be <NUM>. If the receiving device later rejects the request to receive the media stream from one of the transmitting device <NUM> which was accepted earlier, then the counter value may be updated to <NUM>.

At step <NUM>, the MC server <NUM> identifies the one or more receiving devices <NUM> intended to receive the media streams from one or more of the plurality of transmitting devices <NUM> based on an SSRC identifier associated with media streams of each of the one or more of the plurality of transmitting devices <NUM> and the counter value.

At step <NUM>, the MC server <NUM> transmits media streams from the one or more of the plurality of transmitting devices <NUM> to the identified one or more receiving devices <NUM> based on the mapped SSRC identifier and the counter value.

The MC server <NUM> may receive a reception end request from one or more receiving devices <NUM> when the one or more receiving devices <NUM> do not want to receive a media stream from transmitting devices <NUM>. The MC server <NUM> may update the counter value and send a response to the one or more receiving devices <NUM>. The MC server may stop forwarding media streams from transmitting devices <NUM> to the one or more receiving devices <NUM> who ended reception.

The MC server <NUM> may receive a request, from the receiving devices <NUM>, to receive a media stream from each of the one or more transmitting devices <NUM> for the receiving devices <NUM> that ended media reception earlier by sending a reception end request message to the MC server <NUM>.

The MC server <NUM> may transmit an end notification to the receiving devices <NUM> when media transmission from the transmitting devices <NUM> has ended.

<FIG> illustrates a block diagram of a computer system, according to an embodiment.

Referring to <FIG>, the computer system <NUM> may be an MC server <NUM>. The computer system <NUM> includes a central processing unit <NUM> ("CPU" or "processor"). The processor <NUM> may comprise at least one data processor for executing program components for executing user or system-generated business processes. The processor <NUM> may include specialized processing units such as integrated system (bus) controllers, memory management control units, floating point units, graphics processing units, and digital signal processing units.

The processor <NUM> may be disposed in communication with one or more input/output (I/O) devices, such as input device <NUM> and output device <NUM>, via I/O interface <NUM>. The I/O interface <NUM> may employ communication protocols/methods such as, without limitation, audio, analog, digital, stereo, the Institute of Electrical and Electronics Engineers (IEEE)-<NUM>, serial bus, universal serial bus (USB), infrared, personal system (PS)/<NUM>, bayonet Neill-Concelman (BNC), coaxial, component, composite, digital visual interface (DVI), high-definition multimedia interface (HDMI), radio frequency (RF) antennas, S-Video, video graphics array (VGA), IEEE <NUM>. n /b/g/n/x, Bluetooth, and cellular (e.g., code-division multiple access (CDMA), High-speed packet access (HSPA+), global system for mobile communications (GSM), and long-term evolution (LTE)). Using the I/O interface <NUM>, the computer system <NUM> may communicate with the input device <NUM> and/or the output device <NUM>.

The processor <NUM> may be disposed in communication with a communication network <NUM> via a network interface <NUM>. The network interface <NUM> may communicate with the communication network <NUM>. The network interface <NUM> may employ connection protocols including, without limitation, direct connect, ethernet (e.g., twisted pair <NUM>/<NUM>/<NUM> Base T), transmission control protocol/internet protocol (TCP/IP), token ring, and IEEE <NUM>. 11a/b/g/n/x.

The communication network <NUM> can be implemented as one of the several types of networks, such as intranet or local area network (LAN) within the organization. The communication network <NUM> may either be a dedicated network or a shared network, which represents an association of several types of networks that use a variety of protocols, such as hypertext transfer protocol (HTTP), TCP/IP, and wireless application protocol (WAP), to communicate with each other. Further, the communication network <NUM> may include a variety of network devices, including routers, bridges, servers, computing devices, and storage devices.

The processor <NUM> may be disposed in communication with a memory <NUM> including a random access memory (RAM) <NUM> or a read only memory (ROM) <NUM> via a storage interface <NUM>. The storage interface <NUM> may connect to memory <NUM> including, without limitation, memory drives and removable disc drives employing connection protocols such as serial advanced technology attachment (SATA), integrated drive electronics (IDE), IEEE-<NUM>, USB, fiber channel, and small computer systems interface (SCSI). The memory drives may further include a drum, magnetic disc drive, magneto-optical drive, optical drive, redundant array of independent discs (RAID), solid-state memory devices, and solid-state drives.

The memory <NUM> may store a collection of program or database components, including, without limitation, a user/application data <NUM>, an operating system <NUM>, a web browser <NUM>, a mail client <NUM>, a mail server <NUM>, and a web server <NUM>. In some embodiments, computer system <NUM> may store user/application data <NUM> including variables, and records. Such databases may be implemented as fault-tolerant, relational, scalable, secure databases such as OracleR or SybaseR.

The operating system <NUM> may facilitate resource management and operation of the computer system <NUM>. Examples of operating systems <NUM> include, without limitation, Apple MacintoshR operating system (OS) X, UNIXR, UNIX-like system distributions (e.g., Berkeley Software Distribution™ (BSD), FreeBSD™, NetBSD™, and OpenBSD™), Linux Distributions™ (e.g., Red Hat™, Ubuntu™, Kubuntu™, etc.), IBM™ OS/<NUM>, Microsoft™ Windows™ (XP™, Vista™/<NUM>/<NUM>, <NUM> etc.), AppleR IOS™, GoogleR Android™, and BlackberryR OS. A user interface may facilitate display, execution, interaction, manipulation, or operation of program components through textual or graphical facilities. User interfaces may provide computer interaction interface elements on a display system operatively connected to the computer system <NUM>, such as cursors, icons, check boxes, menus, windows, and widgets. Graphical user interfaces (GUIs) may be employed, including, without limitation, Apple MacintoshR OSs, IBM™ OS/<NUM>, Microsoft™ Windows™ (XP™, VISTA™/<NUM>/<NUM>, and <NUM>), UnixR X-Windows, and web interface libraries (e.g., Ajax™, DHTML™, Adobe® Flash™, Javascript™, and Java™).

Furthermore, one or more computer-readable storage media may be utilized in implementing embodiments consistent with the present application. The term "computer-readable medium" should be understood to include tangible items and exclude carrier waves and transient signals, i.e., non-transitory. Examples of computer-readable storage media include RAM, ROM, volatile memory, nonvolatile memory, hard drives, compact disc (CD) ROMs, Digital Video Disc (DVDs), flash drives, disks, and any other known physical storage media.

Accordingly, the present disclosure provides an MC server that effectively configures and controls a number of media streams which can be sent to a particular user dynamically. The MC server starts forwarding the media streams to a receiving device based on a counter value, an SSRC identifier and a user's stream selection.

As discussed above, new state transitions and counter values may be introduced at the MC server to handle the transmission of multiple media streams to a recipient device. Therefore, the present disclosure provides a method and system for handling the reception of a plurality of media streams at a media controller. Thus, the present disclosure provides flexibility for the user to accept the plurality of media streams and to terminate any media stream at any time. Also, the present disclosure provides flexibility to start (or restart) reception of a media stream from an MC server for a media stream which user rejected or ended earlier. The MC server manages the media stream such that the user can accept and terminate reception at any time, and also forwards the media stream to the intended recipient only. The server forwards the media stream only to a recipient device that accepted the stream, and terminates reception by sending a message to the MC server upon request of the recipient device. When the MC server receives the request, the MC server stops sending the media stream to that particular recipient device. Accordingly, the present disclosure avoids complications in handling media streams.

The terms "an embodiment", "embodiment", "embodiments", "the embodiment", "the embodiments", "one or more embodiments", "some embodiments", and "one embodiment" mean "one or more (but not all) embodiments of the invention(s)" unless expressly specified otherwise.

The terms "including", "comprising", "having" and variations thereof mean "including but not limited to", unless expressly specified otherwise.

The enumerated listing of items does not imply that any or all the items are mutually exclusive, unless expressly specified otherwise. The terms "a", "an" and "the" mean "one or more", unless expressly specified otherwise.

A description of an embodiment with several components in communication with each other does not imply that all such components are required. On the contrary, a variety of optional components are described to illustrate the wide variety of possible embodiments of the disclosure.

When a single device or article is described herein, more than one device/article (e.g., if they cooperate) may be used in place of a single device/article. Similarly, where more than one device or article is described herein (e.g., if they cooperate), a single device/article may be used in place of the more than one device or article or a different number of devices/articles may be used instead of the shown number of devices or programs. The functionality and/or features of a device may be alternatively embodied by one or more other devices which are not explicitly described as having such functionality/features. Thus, other embodiments of the disclosure need not include the device itself.

The scope of the disclosure is defined by the appended claims that issue on an application based here on. Accordingly, the embodiments of the present disclosure are intended to be illustrative, but not limiting, of the scope of the disclosure, which is set forth in the following claims.

Claim 1:
A method for handling reception of a plurality of media streams in a mission critical, MC, system, the method comprising:
transmitting, by an MC server (<NUM>), a request to each of one or more receiving devices (<NUM>) for receiving a plurality of media streams from a plurality of transmitting devices (<NUM>);
receiving, by the MC server, a response from each one of the one or more receiving devices (<NUM>) for receiving a number of media streams among the plurality of media streams transmitted by the one or more of the plurality of transmitting devices (<NUM>) and updating the number of media streams to be received by each one of the one or more receiving devices (<NUM>) as a counter value;
identifying, by the MC server, the one or more receiving devices (<NUM>) intended to receive the media streams from the one or more of the plurality of transmitting devices (<NUM>) based on a synchronization source, SSRC, identifier associated with media streams of each of the one or more of the plurality of transmitting devices and the counter value;
transmitting, based on the SSRC identifier and the counter value, by the MC server, media streams from the one or more of the plurality of transmitting devices (<NUM>) to the identified one or more receiving devices;
initializing the counter value to zero and emptying an SSRC list when the MC server enters a first state, wherein the first state is a state of not being permitted to receive media; and
entering the first state from a second state if the counter value reaches a minimum value, wherein the second state is a state of being permitted to receive media.