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 08:39:44 -0600
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-Id: <304A0E9A-48B0-46AC-ABE6-8DA01638F4D7@cisco.com>
To: Iñaki Baz Castillo <ibc@aliax.net>

> On Aug 2, 2017, at 8:31 AM, Iñaki Baz Castillo <ibc@aliax.net> wrote:
> 
>>> 
>>> 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.

So 

https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-26#page-16 <https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-26#page-16>

says 

   WebRTC Endpoints that are sending media are
   REQUIRED to implement support for TMMBR messages, and MUST follow
   bandwidth limitations set by a TMMBR message received for their SSRC.

The last I heard from Chrome team is they planned to implement WebRTC 1.0 and I have not seen them arguing for removing TMMBR from the spec so I am sort of surprised to hear that. It seems like as far the spec goes, the support TMMBR is fairly clear. 

I totally understand that the specs are not done and the browsers don't fully implement specs yet and that people are still trying to figure out what they can get to work now in chrome - but that seems more appropriate for some bugtracker prioritizing chrome features. 
Received on Wednesday, 2 August 2017 14:39:57 UTC

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