The technology disclosed herein relates generally to the field of multiparty conferencing, and in particular to method in a multipoint control unit for congestion control in multiparty conferencing, a multipoint control unit, computer program and computer program product.
Multiparty conferencing is a service that may be provided by a centralized server, wherein participants may join a conference e.g. by dialing a telephone number or, for Internet-based conferences, a destination address. A Multi-Conferencing Unit (MCU), also denoted multipoint control unit, handles signaling, switching, mixing, filtering and forwarding of different media streams, and control exchanges for all participants of the conference.
Congestion control in such centralized multiparty conferences is far from trivial. Several general strategies exist. One strategy is to have a sending participant (sender) deliver the best possible quality supported by it to the MCU. Then for each leg from the MCU to a respective receiving participant (receiver) the MCU performs transcoding if the supported rate between the MCU and the particular receiver is insufficient for the stream that the MCU receives. Transcoding, i.e. decoding the stream and then encoding it in another format, has the drawbacks that it degrades quality, increases end-to-end latency, and is also typically computationally expensive.
Another strategy is to group receivers according to the supported bit-rate between the MCU and the particular receivers. In this way the number of different bit-rates that the MCU needs to produce can be reduced. The bit-rates available for transmission can, for instance, be obtained through transcoding from the sender. This strategy reduces the number of different transcodings needed in the MCU, and hence number of performed transcodings. However, just as for the above described strategy, transcoding is still needed, which as mentioned e.g. degrades the quality.
Self-clocking Rate Adaptation for Multimedia (SCReAM) is a candidate congestion control scheme for Real-time Transport Protocol/Real-time Transport Control Protocol (RTP/RTCP). The scheme is self-clocking which means that the amount of RTP packets that are transmitted is in direct proportion to the amount of RTP packets that are being acknowledged. This makes SCReAM inherently stable in congested situations. Unlike many other multimedia congestion control schemes, the receiver in SCReAM does not communicate a bitrate to the sender (rate based schemes). Instead the sustainable bitrate is inferred by the SCReAM sender, from the acknowledgements sent by the SCReAM receiver. This makes the design of an MCU that supports SCReAM different from an MCU that supports other rate based schemes.
Temporary Maximum media stream Bit Rate Request (TMMBR) is a conceivable solution for a MCU to indicate to the media sender the currently highest bit-rate supported for this stream. However, this solution is sub-optimal for a congestion mechanism such as SCReAM that doesn't regularly arrive at a supported bit-rate decision and instead uses a congestion window and is driven by acknowledgements.
An objective of the present teachings is to improve on multi-party conferencing by increasing quality of received media streams and reducing end-to-end latency, caused to a large extent by the required transcoding. This objective is met, in various embodiments, by providing methods and devices by means of which transcoding can be avoided.
The objective is according to an aspect achieved by a method performed in a multipoint control unit for congestion control in multiparty conferencing. The method comprises forwarding packets of a media stream from the sending part to receiving parts of the multiparty conference, the receiving parts being two or more; receiving, from each receiving part, a respective receiver feedback report on the reception of the packets; establishing a sender feedback report comprising a timestamp for a given packet sequence number, wherein the timestamp reflects a wall-clock time when the packet with the given packet sequence number have been acknowledged by a threshold number of the receiving parts; and providing the established sender feedback report to the sending part.
The method enables a multipoint control unit operation without the need to transcode video streams. This is enabled by providing the sending part with a combined feedback report of the currently supported bit-rates at the receiving parts.
The objective is according to an aspect achieved by a computer program for a multipoint control unit for congestion control in multiparty conferencing. The computer program comprises computer program code, which, when executed on at least one processor on the multipoint control unit entity causes the multipoint control unit to perform the method as above.
The objective is according to an aspect achieved by a computer program product comprising a computer program as above and a computer readable means on which the computer program is stored.
The objective is according to an aspect achieved by a multipoint control unit for congestion control in multiparty conferencing. The multipoint control unit is configured to: forward packets of a media stream from the sending part to receiving parts (4a, 4b, 4c) of the multiparty conference, the receiving parts being two or more; receive, from each receiving part, a respective receiver feedback report on the reception of the packets; establish a sender feedback report comprising a timestamp for a given packet sequence number, wherein the timestamp reflects a wall-dock time when the packet with the given packet sequence number have been acknowledged by a threshold number of the receiving parts; and provide the established sender feedback report to the sending part.
Further features and advantages of the embodiments of the present teachings will become clear upon reading the following description and the accompanying drawings.
In the following description, for purposes of explanation and not limitation, specific details are set forth such as particular architectures, interfaces, techniques, etc. in order to provide a thorough understanding. In other instances, detailed descriptions of well-known devices, circuits, and methods are omitted so as not to obscure the description with unnecessary detail. Same reference numerals refer to same or similar elements throughout the description.
For sake of completeness and in order to provide a thorough understanding of the present invention, the SCReAM congestion control is initially described. The SCReAM congestion control is designed mainly for video, and is similar to Transmission Control Protocol (TCP) with the exception that SCReAM does not ensure any in order delivery up to higher layer. In the following thus, some basics of SCReAM are explained.
First, the scheme, e.g. a sequence of instructions, performed at a sending side is described. The network congestion control performs two main functions: computation of congestion window and transmission scheduling. The computing of congestion window gives an upper limit on the number of bytes in flight i.e. how many bytes that have been transmitted but not yet acknowledged. The transmission scheduling ensures that RTP packets are transmitted only if allowed by a relation between the number of bytes in flight and the congestion window.
Unlike TCP, SCReAM is not a byte oriented protocol; SCReAM is rather an RTP packet oriented protocol. SCReAM keeps a list of transmitted RTP packets and their respective sending times (wall-clock time). The list also comprises a synchronization source identifier used in RTP, denoted SSRC, which uniquely identifies the source of a stream. Still further, the list also comprises payload type (PT) enabling the congestion control to distinguish between streams in cases where the network congestion control schedules many streams. A feedback indicates the highest received RTP sequence number and a timestamp (wall-clock time) when it was received. In addition, an acknowledgement (ACK) list is included in order to enable determination of lost packets.
The feedback format for the SCReAM protocol is under development and a final standardized congestion control using the SCReAM protocol or some derivative thereof that is based on similar ACK clocking principles may use a different feedback format. The SCReAM protocol for real time conversational media might be implemented with Real-time Transport Control Protocol (RTCP) as carrier of the feedback, but other protocols for use as carrier of feedback is also conceivable. Feedback header fields may differ depending on the choice. However, elements in the SCReAM feedback to the sending side (also denoted sender in the following) that are relevant for embodiments according to the present teachings comprise:
In the following, the SCReAM feedback is denoted SCFB.
bytes in flight=bytes(packet SN-2)+bytes(packet SN-1)+bytes(packet SN)
Video rate control in SCReAM is based on measurements of the RTP packet queuing delay in the sender.
Next, the scheme, e.g. a sequence of instructions, performed at the receiving side is described. The receiving side (also denoted receiver in the following) timestamps each received RTP packet and prepares an SCFB packet with feedback elements.
Below, only SCReAM feedback elements from the receiver that are relevant for the present teachings are listed.
The reduction in congestion window is proportional to the amount of SCFB feedback with the Q bit set. The reduction is done once per Round-Trip-Time (RTT), i.e. time from transmission of a packet to reception of acknowledgement thereof.
Letting:
N=Number of received SCFB messages in one RTT
NQ=Number of received SCFB messages in one RTT, with Q bit set.
The new congestion window (CWND) is then expressed as:
cwnd=max(min_cwnd, cwnd*(1.0−0.5* NQ/N))
A CWND increase should be inhibited for one RTT if the CWND has been decreased as a result of Q bits set in the SCFB. It is noted that CWND is adjusted at most once per RTT. The extreme case is if all SCFB feedback has the Q bit set, in which case CWND is halved every RTT.
Briefly, according to the present teachings SCReAM feedback packets from multiple different endpoints are combined in such a way that a sender sees a current reference path from the sender to any of the endpoints via the MCU. Stated differently, the reference path is selected to represent the paths between the sender and the different endpoints. The reference path may, for instance, be the path having the worst quality. In other embodiments, the reference path may be configured to be the N'th worst path to reduce the impairment for the receivers with better paths at the expense of the N-1 that has an even worse path and would thus experience additional impairments. This solution ensures that the sender is enabled to continuously adapt its bit-rate to the actual available path bitrates in the group of receivers.
In the following RTP is used for exemplifying the present teachings. It is however noted that other protocols may be used, for instance Quick UDP Internet Connection (Quic) protocol. It is thus noted that RTP and RTP packets are used purely as an example for illustrative purposes in the description as well as in the figures.
An MCU may forward a media stream, e.g. a video stream, to many receivers in different ways. In
The MCU 1 also comprises a feedback report generator 5 and an UDP socket 9 (or other interface) towards the sender 2. The feedback report generator 5 may be configured to combine the SCFB from the UEs 4a, 4b, 4c according to any of the embodiments described herein, or combination thereof.
According to the teachings, SCFB packets from the MCU 1 to the sender 2 for a given RTP sequence number are transmitted when all UEs 4a, 4b, 4c have acknowledged the given (or a higher) RTP sequence number. The timestamp of the received RTP packet with the highest sequence number, the TSRX, is set to the wall-dock time when all UEs 4a, 4b, 4c have acknowledged the packet with this RTP sequence number. This way the sender 2 will be informed about the available throughput to the UE that has the poorest throughput among receiving UEs 4a, 4b, 4c.
In an alternative embodiment the strict all-must-ACK-rule can be relaxed somewhat. For instance, it may suffice that X% of the UEs ACK the given RTP sequence number, for instance more than 70% of the receivers or more than 90% or 95%. This may be beneficial if wanting to reduce the risk that a single UE out of many UEs that is in poor coverage reduces the bitrate for all UEs. The potential drawback is that the UEs that have not yet acknowledged the RTP sequence number will get a poor quality, so there is a balance to be struck here. In addition, it is possible to transcode or even freeze video for the UEs with poor coverage whose ACK are not taken into account.
As a particular example, it is supposed that a stream is forwarded by the MCU to 10 UEs. The MCU 1 experiences that 9 of the 10 UE generally acknowledge RTP packets within a given time span (TACK90%), while the 10th UE has problems that cause the ACKs to arrive later, for instance due to the 10th UE having poor radio conditions. Instead of letting all to UEs share the fate with the 10th UE that has poor radio, it may be better to exclude that UE from taking part in the feedback from the MCU 1 to the sender 2.
In some embodiments, the stream of this 10th UE (or more UEs if another TACK90% is set) may e.g. be processed in the respective congestion control instances 3a, 6, 7 e.g. by stream thinning or transcoding to a considerably lower bitrate for the UE (or UEs) with poor radio. Stream thinning is a method to selectively remove parts of an encoded stream, with the purpose to achieve a lower bitrate without transcoding and with minimum impact on the result of the decoding process.
The congestion control instances 3a, 6, 7 for each UE may deal with packet loss handling in conventional way, e.g. by having a loss event trigger a reduction of the congestion window.
It would be disadvantageous to let the MCU 1 indicate the sum of all packets lost over each of the respective MCU to receiver paths, as that would give the sender 2 an impression of a situation worse than any of the actual paths. Instead, the MCU 1 may provide the sender 2 with SCFB representing the worst MCU 1 to receiver 4a, 4b, 4c path. This can be done by reporting the number of lost packets on the sender 2 to MCU 1 path combined with the number of lost packets on the worst MCU 1 to receiver 4a, 4b 4c path.
In cases wherein SCFB from a UE 4a, 4b, 4c to the MCU 1 indicates RTP packets as lost and the RTP packets are still stored in the RTP queue in the MCU 1, it is possible to avoid reporting them as lost to the sender 2 and instead retransmit them from the MCU 1. If reporting the packets as lost to the sender 2, the UE 4a, 4b, 4c that indicated the lost packet would then require more data to be sent from the sender 2, which in turn may delay transmission of subsequent RTP packets to the given UE 4a, 4b, 4c, with the potential effect that the returned acknowledgements are also delayed. If the UE 4a, 4b, 4c has poor throughput, acknowledgements from the MCU 1 to the sender 2 will consequently also be delayed, with the possible effect that the sender 2 bitrate is decreased.
An additional consideration is that the SCFB ACK vector (if present) can only indicate reception of a limited number (here 32+1=33) of highest RTP sequence number. This means that if a retransmitted RTP packet is lost again it may not be detected. Recovery by other means is then necessary.
The source quench bit (Q) is used to decrease the congestion window. If any UE 4a, 4b, 4c has indicated that the Q bit is set during a reporting interval, then the MCU 1 may set the Q bit in the next feedback from the MCU 1 to the sender 2. However, due to the non-synchronous reporting, the MCU 1 may need to track if it sent a Q bit to the sender 2 in the last report, and not forward additional receiver Q bits until one reporting interval has passed.
As mentioned earlier, a small number of UEs 4a that have very poor throughput compared to the other UEs 4b, 4c may be excluded from taking part in the feedback from the MCU 1 to the sender 2. An additional feature in this context is to apply transcoding or other processing, such as stream thinning, for these UEs with very poor throughput.
The SCFB elements that may to be combined comprise (for instance):
1. TSRX: i.e. the receiver time stamp corresponding to the highest received RTP sequence number
2. Highest received RTP sequence number
3. ACK vector (if any)
4. Nloss
5. NECN
The highest received sequence number and the ACK list from the SCFBs from the different UEs 4a, 4b, 4c may be combined into one SCFB report to be sent back to the sender 2. As described earlier, an SCFB report with highest sequence number=SN(t) is created and transmitted to the sender 2 at time instant t only when more than X% of the UEs 4a, 4b, 4c have acknowledged RTP sequence number SN(t). X may be less than 100% if it is desired to keep a high bitrate, with the risk that UEs 4a, 4b, 4c with poor coverage gets a poor performance.
The creation of the ACK list may, for instance, be implemented such that all bits are originally set to ‘1’. If any of the UEs 4a, 4b, 4c have indicated a lost packet for a given sequence number, then the corresponding bit in the combined SCFB report is set to ‘2’. As described earlier, consideration has to be taken so as to not cause poor throughput due to the combination of packet loss indications. One alternative is to select the ACK vector for the UE 4a, 4b, 4c with the worst conditions or notify the sender 2 about the number of receivers 4a, 4b, 4c. The sender 2 can then take into account the number of receivers 4a, 4b, 4c when responding with appropriate action to the loss events, and not reduce the congestion window too much.
In another embodiment, a combined Nloss counter may be implemented, such that it is increased whenever the Nloss feedback element from any of the receivers 4a, 4b, 4c increases. Similar to the reasoning above, this can cause poor throughput due to the accumulated packet loss sensitivity. In some embodiments therefore, only the Nloss feedback elements from the worst off receiver 4a, 4b, 4c are considered.
The handling of the NECN counters may be implemented in a manner corresponding to what has been described for the Nloss counter.
The combination function to get the TSRX for the combined feedback packet requires some extra effort when implementing the MCU to according to the embodiment of
Letting a first UE 4a be the first UE that joins a session. The TSRX for this first UE 4a is then a vector TSRX(SN) where SN is the highest received sequence number corresponding to the given TSRX. A UE-specific offset is computed from the vector. Typically the offset is given already by the first received feedback but a more advanced function can iteratively determine a more accurate offset, taking into account that even the first packet may have been subject to delay jitter, which then requires the RTP timestamp and knowledge about the RTP sampling rate.
When a new UE arrives, a second UE 4b, the same procedure to obtain a new UE-specific offset is repeated. In the combined SCFB report from the MCU 10 to the sender 2, the TSRX will use the obtained offsets in order to create a TSRX(SN) that is consistent, i.e. does not show discontinuities when changing which UE that dictates the transmission of the feedback report to the sender 2.
This procedure may be needed as it is the UE SCFB report that is the last to acknowledge a given sequence number that sets the TSRX. Since channel conditions can vary, the “last” UE 4a, 4b, 4c to report may vary over time.
The value of the Q bit from the respective receivers 4a, 4b, 4c is forwarded by the MCU 10 to the sender 2. If any receiver 4a, 4b, 4c has indicated that the Q bit is set, during a reporting interval, then the MCU 10 shall set the Q bit in the next feedback from the MCU 10 to the sender 2. However, due to the non-synchronous reporting, the MCU 10 will need to track if it sent a Q bit to the sender 2 in the last report, and not forward additional receiver Q bits until at least one reporting interval has passed. This is in line with the Q bit handling of the embodiment illustrated in
The MCU 20 also comprises a switch 21 that switches between streams.
The switch 21 is configured with conventional switching functionality, such as for example transmission of Full Intra Request (FIR) to the sender 2a, 2b which is being switched in, to get a clean decoder starting point at the point of switch. SCReAM does not impose any changes in this respect. An efficiently compressed, encoded representation of media (e.g. video) typically involves sending a difference from previous media samples (like a video picture). Therefore, obtaining a “starting point” for a receiver that did not receive the previous samples requires sending a request to the media-sending encoder that it should send a media sample that does not use such difference from previous samples. It is noted that FIR is only one specific example of such request (i.e. request to send a starting point by not using any difference for a media sample). This request is necessary, since the sender in general does not know when the media stream it sends is “switched in” by the MCU, that is, when the media stream is being forwarded to a receiver that does not have the history of differences needed to decode the media.
The stream that is currently forwarded as active is acknowledged as has been described in relation to
Senders 2a, 2b that are inactive (i.e. media is not forwarded) pose an additional challenge in that it is unknown what the end-to-end characteristics would be if the senders were not inactive. This may be implemented such that to acknowledge the received RTP packets directly as they are received by the MCU 20. However, doing so may create an unnatural jump in one way delay when the stream is switched to active (i.e. is being forwarded) and the information in the SCFB reports are based on measurements all the way from the downlink receivers 4a, 4b instead of just from the
MCU 20. A conceivable solution is to delay the acknowledgements DInactive corresponding to the RTT measured over the link in the direction from the MCU 20 to the receivers 4a, 4b. Typically, it is the path between the MCU 20 and the receiver 4a, 4b with the longest RTT that dictates the delay, but in case for instance the X% of the receivers 4a, 4b rule, described earlier, is applied, then the delay may instead be determined from the receivers 4a, 4b that actually participate in the feedback to the sender 2a, 2b. With this in place, the one way delay measured by the senders 2a, 2b will be minimally affected by the switching.
The case when no receivers 4a, 4b are (yet) connected pose a minor challenge, as there is not yet any RTT estimates for the links between the MCU 20 and the prospective receivers 4a, 4b. DInactive is therefore initialized to an estimate of the RTT that is likely to occur once receivers 4a, 4b connect.
An alternative to the above is to transmit an SCFB report to the inactive senders that indicate that all is fine, regardless of the status between the sender 2a, 2b to MCU 20 path. Yet another alternative is to indicate explicitly in a bit in the SCFB report that the sender 2a, 2b is becoming active, meaning that the path reported on has changed from MCU 20 only to now also include the MCU to receiver path, in which case the sender 2a, 2b can take appropriate actions to ensure that the sender's congestion control is working properly. An example on such an action may be to reset the base delay history. The base delay history is used in SCReAM to estimate the queuing delay. The timestamp clocks on sender and receiver side are not synchronized. This means that it is not possible to measure the exact time that it takes for a packet to travel from sender to receiver. Instead, the method used is to estimate the base delay in order to estimate the queuing delay in the network. The base delay is computed as the min value of TSTX and TSRX for each RTP packet that is acknowledged according to:
baseDelay=min(baseDelay, TSRX−TSTX); baseDelay is initialized to a very high value
The baseDelay may become invalid over time, e.g. due to route changes. For this reason a history of baseDelays (baseDelayHistory) is maintained and updated e.g. every 10 seconds. The size of the baseDelayHistory vector is limited to e.g. 20 elements, which means that old baseDelay estimates are shifted out over time. For each packet that is acknowledged, the one way delay (OWD) is computed as
OWD=TSRX−TSTX−min(baseDelayHistory)
In the MCU case, it is possible that each host sends two or more streams representing the same content but with different quality (simulcast). Support for this may be implemented by means of a corresponding number of additional RTP packet queues for each SCReAM instance (addressing a respective receiver 4a, 4b). The management of the SCFB reports to the senders 2a, 2b is in this case somewhat simpler as all simulcast senders in the same host are to be considered either “active” or “inactive”.
The various features and embodiments that have been described may be combined in different ways, examples of which are given in the following with reference first to
The method 30 comprises forwarding 31 packets of a media stream from the sending part 2 to receiving parts 4a, 4b, 4c of the multiparty conference, the receiving parts 4a, 4b, 4c being two or more.
The method 30 comprises receiving 32, from each receiving part 4a, 4b, 4c , a respective receiver feedback report on the reception of the packets.
The method 30 comprises establishing 33 a sender feedback report comprising a timestamp TSRX for a given packet sequence number, wherein the timestamp reflects a wall-clock time when the packet with the given packet sequence number have been acknowledged by a threshold number of the receiving parts 4a, 4b, 4c. The sender feedback report may be seen as indicating a reference path which is representative for (or applicable to) each receiving part 4a, 4b, 4c. The packet with the given packet sequence number may be acknowledged by a receiver explicitly by an acknowledgment for this particular packet, or it may be acknowledged through a later sequence number. That is, the packet with the given packet sequence number may be s acknowledged by indicating in the feedback a packet sequence number that is higher together with indication of no packet losses having occurred (e.g. using the ACK vector in case of SCReAM), hence also acknowledging the given packet.
The method 30 comprises providing 34 the established sender feedback report to the sending part 2.
According to the present teachings, the sender is provided with information on the supported rate within the receiver group and adapts the rate to one suiting all the receivers. The method 30 avoids the need for transcoding e.g. video streams in the multipoint control unit. This is in contrast with prior art, wherein the sender knows the best rate for each receiver or group of receivers and the MCU is forced to perform transcoding or transrating to adjust the bit-rate to a more suitable rate depending on the particular conditions for the different receivers. In prior art, also in cases where simulcast is used, lack of knowledge of the currently supported bit-rates can result in the receiver being forced to receive media with a lower quality than what could be achieved if the sender knew the supported rate within the targeted group.
In various embodiments, the threshold number of receiving parts 4a, 4b, 4c having acknowledged the packet is set to more than 50% of all receiving parts 4a, 4b, 4c, or by more than 70%, or by more than 90%, or by more than 95% or by 100% of all receiving parts 4a, 4b, 4c.
In some embodiments, the establishing 33 comprises determining the timestamp TSRX such that one or more receiver feedback reports are excluded. It is noted that a receiver feedback report may be excluded for different reasons. The receiver feedback report may be excluded because it was never sent and can hence not be received, or because it was sent but still not received e.g. being in transit or being lost, or because it is explicitly excluded, i.e. excluded by choice. The receiver feedback report could, as have been described, be excluded by choice for a receiving part with very poor reception conditions, in order for this receiving part to not affect the quality of the other receiving parts too much.
In a variation of the above embodiment, the method 30 comprises transcoding or stream thinning the media stream for each of the one or more receiving parts 4a, 4b, 4c for which a receiver feedback report is excluded.
In various embodiments, the method 30 comprises retransmitting a packet to a receiving part 4a, 4b, 4c that has indicated in its feedback report the packet as lost. If the multi-point control unit 1, 10 has the packet available, then it may send the packet to a receiving part 4a, 4b, 4c having indicated the packet as lost, alleviating the sender from having to resend it and thus reducing delay.
In various embodiments, the method 30 comprises setting a source quench bit in the sender feedback report when at least one received feedback report from the at least two receiving parts 4a, 4b, 4c comprises a source quench bit being set.
In various embodiments, the multipoint control unit 1, 10 utilizes feedback elements of Self-clocking Rate Adaptation for Multimedia, SCReAM, congestion control.
In various embodiments, the received receiver feedback reports comprise a feedback element, Nloss, counting accumulated number of lost packets, and the method 30 comprises: increasing a counter C1 whenever a received feedback report indicates an increase in the feedback element, Nloss, and including a feedback element, Nloss, in the sender feedback report based on the counter C1 value.
In various embodiments, the method 30 comprises switching between a first and a second sender and wherein the providing 34 comprises providing a respective sender feedback report with a delay calculated based on a round trip delay between the multipoint control unit and one or more of the receiving parts 4a, 4b, 4c.
The a multipoint control unit 1, 10 comprises a processor 40 comprising any combination of one or more of a central processing unit (CPU), multiprocessor, microcontroller, digital signal processor (DSP), application specific integrated circuit etc. capable of executing software instructions stored in a memory 41 which can thus be a computer program product 41. The processor 40 can be configured to execute any of the various embodiments of the method for instance as described in relation to
The memory 41 can be any combination of read and write memory (RAM) and read only memory (ROM), Flash memory, magnetic tape, Compact Disc (CD)-ROM, digital versatile disc (DVD), Blu-ray disc etc. The memory 41 may also comprise persistent storage, which, for example, can be any single one or combination of magnetic memory, optical memory, solid state memory or even remotely mounted memory.
The multipoint control unit 1, 10 comprises one or more interface 8, 9 for communicating with other devices, in particular with sending parts and receiving parts as has been described earlier. Such interface may for instance comprise one or more UDP sockets. The interface 8, 9 may comprise means, e.g. interfaces, protocol stacks etc. and the multipoint control unit 1, 10 may for instance receive receiver feedback reports from receiving parts of the multiparty conferencing and transmit sender feedback reports to sending parts by means of such interface(s).
The multipoint control unit 1, 10 comprises a feedback report generator 5, as has been described earlier with reference e.g. to
The multipoint control unit 1, 10 may optionally, in some embodiments, comprise congestion control instances 45, e.g. comprising congestion control 7, transmission scheduler 6 and queue handling 3a, as has been described earlier with reference to
The multipoint control unit 1, 10 may optionally, in some embodiments, comprise switching means 21 for switching between streams sent from two or more sending parts. Such switching means 21 has been described with reference to
The multipoint control unit 1, 10 may comprise additional processing circuitry, schematically indicated at reference numeral 44, for implementing the various embodiments according to the present teachings.
The present teachings provide computer programs 42 for the multipoint control unit 1, 10 for congestion control in multiparty conferencing. The computer program 42 comprises computer program code, which, when executed on at least one processor 40 of the multipoint control unit 1, 10 causes the multipoint control unit 1, 10 to perform the method 30 according to any of the described embodiments thereof.
The present disclosure also encompasses computer program products 41 comprising a computer program 42 for implementing the embodiments of the method as described, and a computer readable means on which the computer program 42 is stored. The computer program product, or the memory, thus comprises instructions executable by the processor 40. Such instructions may be comprised in a computer program, or in one or more software modules or function modules. The computer program product 41 may, as mentioned earlier, be any combination of random access memory (RAM) or read only memory (ROM), Flash memory, magnetic tape, Compact Disc (CD)-ROM, digital versatile disc (DVD), Blu-ray disc etc.
A multipoint control unit 1, 10 is provided for congestion control in multiparty conferencing. The multipoint control unit 1, 10 is configured to:
The multipoint control unit 1, 10 may be configured to perform the steps of the described embodiments e.g. by comprising a processor 410 and memory 41, the memory 41 containing instructions executable by the processor 40, whereby the multipoint control unit 1, 10 is operative to perform the steps.
In various embodiments, the threshold number of receiving parts 4a, 4b, 4c having acknowledged the packet is set to more than 50% of all receiving parts 4a, 4b, 4c or by more than 70%, or by more than 90%, or by more than 95% or by 100% of all receiving parts 4a, 4b, 4c.
In various embodiments, the multipoint control unit 1, 10 is configured to establish by determining the timestamp TSRX such that one or more receiver feedback reports are excluded.
In various embodiments, the multipoint control unit 1, 10 is configured to transcode or stream thin the media stream for each of the one or more receiving parts 4a, 4b, 4c for which a receiver feedback report is excluded.
In various embodiments, the multipoint control unit 1, 10 is configured to retransmit a packet to a receiving part 4a, 4b, 4c that has indicated in its feedback report the packet as lost.
In various embodiments, the multipoint control unit 1, 10 is configured to set a source quench bit in the sender feedback report when at least one received feedback report from the at least two receiving parts 4a, 4b, 4c comprises a source quench bit being set.
In various embodiments, the multipoint control unit 1, 10 is configured to utilize feedback elements of Self-clocking Rate Adaptation for Multimedia, SCReAM, congestion control.
In various embodiments, the received receiver feedback reports comprise a feedback element, Nloss, counting accumulated number of lost packets, and the multipoint control unit 1, 10 is configured to: increase a counter C1 whenever a received feedback report indicates an increase in the feedback element, Nloss, and to include a feedback element, Nloss, in the sender feedback report based on the counter C1 value.
In various embodiments, the multipoint control unit 1, 10 is configured to switch between a first and a second sender and configured to provide a respective sender feedback report with a delay calculated based on a round trip delay between the multipoint control unit and one or more of the receiving parts 4a, 4b, 4c.
A multipoint control unit 1, to for congestion control in multiparty conferencing is provided. The multipoint control unit 1, to comprises first means 51 for forwarding packets of a media stream from the sending part to receiving parts of the multiparty conference, the receiving parts being two or more.
The multipoint control unit 1, to comprises second means 52 for receiving, from each receiving part, a respective receiver feedback report on the reception of the packets.
The multipoint control unit 1, to comprises third means 53 for establishing a sender feedback report comprising a timestamp for a given packet sequence number, wherein the timestamp reflects a wall-clock time when the packet with the given packet sequence number have been acknowledged by a threshold number of the receiving parts.
The multipoint control unit 1, to comprises fourth means 54 for providing the established sender feedback report to the sending part.
The multipoint control unit 1, to may comprise still further means for implementing the various embodiments of the method 20 that have been described.
The invention has mainly been described herein with reference to a few embodiments. However, as is appreciated by a person skilled in the art, other embodiments than the particular ones disclosed herein are equally possible within the scope of the invention, as defined by the appended patent claims.
Filing Document | Filing Date | Country | Kind |
---|---|---|---|
PCT/EP2015/076675 | 11/16/2015 | WO | 00 |