Hi, In section 8.1, item 1) requires each stream to be congestion controlled, but it does not say by who. 3) also does not specify the congestion control point. Can we make any statement about sender side vs receiver side congestion management i.e. is it acceptable to create a webrtc sender which does not run a congestion control algo, but can act on TMMBR commands on the other side. Should we have a way for the sender and the receiver to negotiate who will run the congestion control? Sorry if this has been already debated in the forum before, I couldn't find much in the mailing list archive. there are some spelling errors as well, "hetrogenous", "banwidth", "indendently", "Limiations" (heading of section 8.2) -thanks, Abheek On Tue, Nov 1, 2011 at 8:22 PM, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
Hi,
We authors decided to put in some text in draft-ietf-rtcweb-rtp-usage-01 around congestion control. See section 8 of https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/
We appreciate feedback if we are in error or if it is a good start that can be considered to have WG consensus and be extended upon.
Cheers
Magnus Westerlund
---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ----------------------------------------------------------------------
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion