W3C home > Mailing lists > Public > public-webrtc@w3.org > December 2013

Re: Material (again!) for scoping discussion

From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 25 Dec 2013 09:09:27 -0500
Message-ID: <CABcZeBO13aGe7FtU=ya1_VKt-VxW67Lp5PUZe8uOg6roeXuf-w@mail.gmail.com>
To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
On Wed, Dec 25, 2013 at 8:46 AM, Stefan Håkansson LK
<stefan.lk.hakansson@ericsson.com> wrote:
> On 19/12/13 17:01, Eric Rescorla wrote:
>> On Thu, Dec 19, 2013 at 6:10 AM, Stefan Håkansson LK
>> <stefan.lk.hakansson@ericsson.com> wrote:
>>> Hi all,
>>> we've now gone through the list of items that could be in/out of 1.0 of
>>> WebRTC, and developed our opinion.
>>> Clue for reading (most should be obvious): when there is a strange name
>>> in the "Can be own spec?" column we propose creating a separate document
>>> (with that working name).
>>> Sorry for the very short notice, we'll talk more about this at the
>>> telechat in a little less than five hours.
>> I've gone through this list and it makes me pretty sad; this seems
>> like a recipe for a system which is primarily useful for demos, but
>> not suitable for building the range of applications that people really
>> expect.
>> As a worked example of this, let's start by considering track
>> rejection and hold. If I am on a low bandwidth link and someone offers
>> me video, I need to be able to reject it; it's not enough to just not
>> display the video, since it's still chewing up bandwidth.  So, this
>> seems like a fairly critical feature for a minimally functional
>> system, and yet the chair's proposal is to defer past 1.0. How
>> can this work?
> In recent time I think there has been one proposal dealing with
> rejection [1]. There was one comment on rejection [2] (incidentally
> given by me) basically saying "your proposal looks good, but not sure we
> need this now".
> So based on recent discussion this does not seem like something a lot of
> people want. And, I guess there are always the options of signaling
> (outside the SDP) to the sender to switch off video, or munging the SDP.

I don't think you can draw this inference.

However, the suggestions you make above for how to address this
are precisely why I suggested it as a test case for discussing the principles
to use for how to make these decisions (which seems to me to be a
lot more useful than trying to discuss each issue one at a time). I don't
consider it acceptable to have basic functionality like this to either
require SDP munging or out-of-band signaling.

Received on Wednesday, 25 December 2013 14:10:38 UTC

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