W3C home > Mailing lists > Public > public-webrtc@w3.org > August 2017

Re: API or spec to limit a certain sending track

From: Cullen Jennings (fluffy) <fluffy@cisco.com>
Date: Wed, 2 Aug 2017 13:54:23 +0000
To: Iñaki Baz Castillo <ibc@aliax.net>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <4531C406-D289-47AB-9C22-C0317FA2B925@cisco.com>

> On Aug 1, 2017, at 12:08 PM, Iñaki Baz Castillo <ibc@aliax.net> wrote:
> On Fri, Jul 28, 2017 at 4:38 PM, Cullen Jennings (fluffy)
> <fluffy@cisco.com> wrote:
>> Another approach is to use the priority API.
> Honestly, I don't think that fits the use-case I exposed. I really
> want to control the maximum bitrate of each sending track, not just
> prioritizing one of them.

I agree it is a different case but given the JS has no good way to know the current state of the congestion controller, it often turns out this is a better approach. Without it is is hard to decide what bitrate you want to assign to each track as you don't know the total available bandwidth. 

>> It also depends on which side end wants to controls this. If the SFU is makeing the decisiong on what is important, then the best option is much differnt than if the JS in the browser is making the decision. Lots of SFU do use SDP to controls this thought I would not suggest that the client JS munging SDP was a good approach to this.
> I'm open to both approaches (that's why I proposed client side and
> server side posible approaches).
> Regarding SDP mungling, I think I just dropped it. Anyhow, I don't
> think it's possible to mungle a SDP to tell the browser "hey, send
> this track with this max bitrate and this other track with this other
> max bitrate".

Uh, setting the b= lines in SDP would do this. Am I missing why this does not work ?

> -- 
> Iñaki Baz Castillo
> <ibc@aliax.net>

Received on Wednesday, 2 August 2017 13:54:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:36 UTC