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

Re: API or spec to limit a certain sending track

From: Iñaki Baz Castillo <ibc@aliax.net>
Date: Wed, 2 Aug 2017 16:31:08 +0200
Message-ID: <CALiegfmw_068hJ8RKCgdN7Dt2gJHxt+dkU16nYmT-oRLq2NxxQ@mail.gmail.com>
To: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
On Wed, Aug 2, 2017 at 4:24 PM, Cullen Jennings (fluffy)
<fluffy@cisco.com> wrote:
>> 1) Mangling the SDP is not the way to go (and theoretically will be prohibited).
>
> But this is not mangling SDP between CreateOffer and setLocat, it has having you server set bandwidth in the SDP.

Sorry, right. b= should be set in the remote SDP.


>> 2) Even if allowed, having to mangle the SDP and perform a fake SDP
>> O/A local renegotiation is not cool at all. Note that, in my use case
>> above, the bitrate limit is decided by the server at any time).
>
> not sugesting that

But that would be the way: a setRemoteDescription(mangledOffer) +
createAnswer() + setLocalDescription() every time the server wants to
change the maximum bitrate of our track.


>> 3) It does not work in PlanB if I send two video tracks because b= is
>> per media (and not per "ssrc").
>
> Plan B is not part of webrtc and no idea why we are even discussing it on this list

Because UNfortunately WebRTC around the world is 95% Chrome based...
And since Chrome does NOT want to implement TMMBR (they want to drop
it) I cannot use the real standard for this (which would be TMMBR). :(

Regards.

-- 
Iñaki Baz Castillo
<ibc@aliax.net>
Received on Wednesday, 2 August 2017 14:31:52 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:51 UTC